Cifrado de aplicación y búsqueda: lo que decidimos no indexar

Cifrar el contenido en la capa de aplicación y, además, indexarlo para búsqueda de texto anula el cifrado, porque el índice guarda una copia legible de lo que se cifró. Por eso Igniten no indexa el contenido cifrado: la búsqueda léxica opera sólo sobre metadatos en claro. El costo es que las búsquedas de frase exacta funcionan peor.

Casi todo lo que un proveedor publica sobre su producto es una lista de capacidades. Cuando el producto lee el correo, los documentos, las reuniones y las bases de datos de una empresa, esa lista deja de ser lo más útil: un sistema con ese acceso puede hacer casi cualquier cosa. La pregunta que ordena una evaluación es la opuesta: ¿qué eligieron deliberadamente que el sistema no pueda hacer, y a cambio de qué? Esta nota es una de las respuestas de Igniten.

¿Qué es el cifrado en la capa de aplicación?

El cifrado en la capa de aplicación es el que cifra el contenido antes de guardarlo en la base, con una clave que controla la aplicación y no el disco. En Igniten, cada organización tiene su propia clave de datos, y con ella se cifran los resúmenes, los fragmentos indexados y las credenciales de integración. Es un esquema de cifrado de sobre: la clave de cada organización está envuelta por una clave maestra en un servicio gestionado de claves, y el cifrado es autenticado.

Esa capa está por encima del cifrado del volumen, no en lugar de él. La razón de tener las dos es concreta:

	Cifrado de volumen	Cifrado en la capa de aplicación
Qué protege	El disco	El contenido, organización por organización
Quién ve el contenido en claro	Cualquier proceso que lea la base a través del motor	Sólo el proceso que tiene la clave de esa organización, mientras la necesita
Un acceso a la base, un respaldo o una réplica	Quien consulta a través del motor lee el contenido en claro	No alcanza para leer contenido
Borrado de una organización	Hay que recorrer cada copia	Destruir la clave vuelve ilegible todo

¿Por qué cifrar y buscar por texto tiran para lados opuestos?

Porque un índice de texto necesita el texto. El índice que permite buscar «contrato de arrendamiento» y encontrar los documentos que contienen esa frase no trabaja con una versión cifrada: guarda fragmentos legibles del contenido para poder compararlos. Un índice invertido o uno trigramático son, en la práctica, otra forma de almacenar el texto.

Si el contenido se cifra y además se indexa como texto, el índice se convierte en una copia legible de lo que se cifró. Todo el trabajo del cifrado de aplicación se anula, y de la peor manera: con la apariencia intacta de estar protegido. Un acceso al índice alcanzaría para leer lo que el cifrado debía proteger.

¿Qué decidimos no indexar?

El contenido cifrado. La recuperación de Igniten —la etapa de búsqueda de un sistema de RAG, que encuentra los fragmentos relevantes antes de que el modelo redacte— combina dos ramas:

• Una rama vectorial, sobre incrustaciones, que busca por significado.
• Una rama léxica, que busca por coincidencia de texto mediante un índice trigramático.

La rama léxica opera exclusivamente sobre metadatos en claro: títulos, nombres de archivo, participantes de una reunión, fechas. Esos campos están sin cifrar de forma deliberada, porque la búsqueda por texto los necesita y porque el riesgo de que un título sea legible es de otra magnitud que el de que lo sea el cuerpo del documento.

El contenido cifrado nunca se indexa para búsqueda de texto. No hay excepción para casos especiales ni configuración que lo habilite. Los vectores tampoco están cifrados, porque un vector cifrado no se puede comparar por similitud; esa es otra renuncia, del lado opuesto, y se trata al darse de baja, como se explica más abajo.

¿Qué búsquedas funcionan peor por esta decisión?

Las de frase exacta que aparece en el cuerpo de un documento y no en su título. La rama vectorial las recupera por significado, lo que funciona bien para preguntas conceptuales —«¿qué acordamos sobre la penalidad por demora?»— y claramente peor para una cadena literal:

• un número de orden que sólo figura dentro de un adjunto;
• una cláusula que hay que citar palabra por palabra;
• un nombre propio poco frecuente que aparece una vez en la página cuatro.

En esos casos el sistema encuentra los documentos sobre el tema, y no necesariamente el que contiene la cadena exacta. Quien viene de buscar con Ctrl+F sobre una carpeta compartida nota la diferencia.

Lo compensan los metadatos en claro —título, archivo, participantes, fecha—, que resuelven buena parte de los casos, y la rama vectorial, que resuelve buena parte del resto. Queda un remanente que funciona peor, y conviene saberlo antes de contratar.

¿Qué se gana a cambio?

Dos cosas, y la segunda pesa más en una evaluación.

Un acceso al almacenamiento no alcanza para leer contenido. Ni a la base, ni a un respaldo, ni a una réplica. El escenario que esto cubre no es el ataque sofisticado sino el más común: una credencial de infraestructura filtrada, una copia de seguridad expuesta por error, una réplica de lectura accesible desde donde no debería.

El borrado deja de depender de un proceso. Como cada organización tiene su propia clave, destruirla vuelve indescifrable todo su contenido de una sola vez, incluidos los respaldos, sin recorrerlos ni reescribirlos. Es lo que se conoce como borrado por destrucción de clave. Nadie que retenga respaldos puede cumplir de verdad una promesa de borrado total instantáneo si depende de sobrescribir cada copia; con la clave destruida, los bytes que quedan no significan nada.

La baja tiene entonces dos mecanismos y dos plazos, y la constancia que se entrega indica los dos, con su fecha:

1. El contenido cifrado se vuelve indescifrable de inmediato al destruir la clave.
2. Los metadatos y los vectores, que no están cifrados porque la búsqueda los necesita, se eliminan por procedimiento: salen de los sistemas activos en el momento y terminan de desaparecer cuando caduca la última ventana de respaldo que los contenía.

Del mismo diseño sale otra consecuencia: las direcciones de correo que forman las listas de acceso tampoco se guardan en claro. Se guarda un resumen calculado con la clave de la organización. La comparación de permisos funciona idéntico, y quién habló con quién no es legible en la base ni en un respaldo, tampoco para Igniten.

¿Por qué preguntarle a un proveedor qué decidió no hacer?

Porque las renuncias son informativas y las capacidades no. Todo producto que lee la información de una empresa enfrenta la misma familia de decisiones:

• indexar más para buscar mejor, o menos para exponer menos;
• guardar el contenido de las reuniones o sólo sus metadatos;
• permitir que el asistente ejecute acciones solo, o exigir confirmación humana en cada una.

Ninguna es gratis. Un proveedor que enumera capacidades sin nombrar ninguna renuncia describe un producto en el que las renuncias no se tomaron. Cuando evalúe una herramienta de esta categoría, después de la lista de lo que hace, pregunte qué decidió no hacer y qué le costó. Una respuesta específica, con el caso de uso concreto que funciona peor, es de otra calidad que una genérica.

Es una pregunta de gobernanza de datos antes que de tecnología, y aplica igual a cualquier agente de IA con acceso a información interna. Otras dos decisiones del diseño de Igniten que limitan al propio proveedor están en por qué el asistente no ejecuta nada sin confirmación humana y en quién controla el acceso de una aplicación de terceros a Google Workspace.

El resto de los mecanismos —la separación entre organizaciones con seguridad a nivel de fila forzada por el motor, el control de acceso por elemento, el inventario de controles fila por fila— está en la documentación técnica de seguridad. Las preguntas sobre inteligencia artificial de un cuestionario de proveedor incluyen las dos cosas que decidimos no publicar y el motivo de cada una. La plataforma está en beta privada, y esas páginas describen sus controles en disponibilidad general. Cómo se sostiene todo esto una vez que la IA ya está en uso se trabaja en el gobierno de IA en producción, y las demás notas del tema están en el tema de gobernanza de IA del blog.