killari.ai: por qué buscar en tus documentos no es lo mismo que entenderlos
El tercer producto que construimos en CloudComputing Perú es killari.ai, y lo definimos como operador de conocimiento institucional. La frase suena a categoría inventada, así que este artículo explica qué hay detrás, en qué se diferencia de un buscador con inteligencia artificial y dónde está el límite de lo que puede hacer.
El problema que ya conocíamos
Llevamos años implantando sistemas de gestión documental en entidades del Estado peruano. En todos ellos aparece la misma escena: la información está, alguien la digitalizó, el expediente existe, y aun así la pregunta concreta —cuál es el tope de viáticos, qué directiva rige hoy para esta compra, qué se acordó en el acta del trimestre pasado— se responde llamando a la persona que lleva más años en la oficina.
El problema no es de almacenamiento. Es que el documento está guardado pero no está entendido, y la organización depende de quien recuerda cuál de las tres directivas sigue vigente.
Tres capas, y las dos de arriba son las que cuestan
killari.ai se organiza en tres capas, y la distinción importa porque explica qué se puede comprar hecho y qué no.
Capa 1, búsqueda agéntica. Encontrar el párrafo relevante dentro de un corpus grande, con búsqueda híbrida y reordenamiento. Es lo que hace cualquier buscador con inteligencia artificial hoy y, dicho sin rodeos, es una capacidad de mercado. Sirve, pero no distingue a nadie.
Capa 2, inteligencia documental. Saber qué documento es y qué resuelve: identificar que esto es una resolución, extraer su número, su fecha, quién la emite y qué dispone. Una ficha tipada, dato a dato, no un resumen. Aquí es donde el producto está ajustado a los tipos documentales peruanos, que es una diferencia real frente a herramientas pensadas para el documento corporativo estadounidense.
Capa 3, memoria institucional. Saber si una norma o una política sigue vigente y por cuál fue reemplazada. Es la capa que responde a la pregunta que de verdad hace la gente, que nunca es «encuéntrame la directiva» sino «¿cuál aplico hoy?».
La capa 3 necesita la 2: no se puede saber qué norma derogó a cuál si antes no se sabe qué es cada documento. Por eso no se llega ahí con un parche encima de un buscador.
Y hay una decisión de diseño que no conviene pasar por alto: la derogación se propone, nunca se aplica sola. Que un documento deje de estar vigente lo confirma una persona del equipo. Un sistema que decidiera solo qué norma murió sería exactamente el tipo de automatización que no queremos en una entidad pública.
No solo responde: genera
La segunda mitad del producto es la que lo separa de un asistente de preguntas. Con el módulo de generación, produce documentos reales en Word, Excel o PowerPoint a partir de las plantillas de la organización, rellenando los datos del conocimiento y manteniendo el formato corporativo.
El detalle que más nos importa de esa función: si un campo requerido no está en el conocimiento ni en la conversación, lo pregunta en lugar de inventarlo. Es la diferencia entre una herramienta que ayuda y una que fabrica un documento verosímil y equivocado.
Y puede actuar sobre los sistemas que ya usa la organización: crear el ticket, avisar en el canal correspondiente, todo con permisos y auditado. Las integraciones van por MCP, sin conectores a medida.
Lo que hace falta para que una institución lo pueda usar
Aquí es donde muchos proyectos de inteligencia artificial se caen, y no por la parte de la inteligencia artificial.
- Soberanía del dato. Funciona en la nube o dentro de la propia infraestructura de la entidad, y con modelos locales la información no sale de su entorno.
- Permisos heredados. Respeta los permisos que ya existen en la fuente, con control por unidad organizativa y acceso por documento. Un asistente que responde a todos con todo es un incidente esperando su fecha.
- Autenticación con lo que ya hay. SSO por OIDC o LDAP, con Google Workspace, Azure AD o Keycloak. Sobre Keycloak en el Estado ya escribimos aquí, porque lo hemos implantado.
- Auditoría completa. Qué fragmentos se usaron, qué se decidió y qué acciones se ejecutaron sobre los sistemas.
- Los datos no se usan para entrenar modelos.
Ninguna de esas cinco es una funcionalidad vistosa. Las cinco son las que deciden si el área legal de una entidad autoriza el piloto.
Dónde está el límite, y lo dice el propio producto
En la interfaz de killari.ai, debajo del campo de preguntas, aparece este aviso: «Las respuestas pueden contener imprecisiones; verifícalas con la documentación oficial».
Está ahí a propósito y no pensamos quitarlo. Un sistema que cita la fuente exacta de cada respuesta hace algo muy valioso, que es permitirte comprobarlo en un clic. Lo que no hace, ni debe pretender, es sustituir el criterio de quien firma. En un procedimiento administrativo el que responde es el funcionario, no la herramienta.
Por eso el producto se diseñó para que verificar sea barato: cada respuesta trae de dónde salió.
Cuándo tiene sentido
Cuando la organización tiene mucho documento normativo propio que cambia —directivas, resoluciones, manuales de procedimiento, actas— y la respuesta correcta depende de saber cuál está vigente. Ese es el caso de un gobierno regional, de una entidad pública con procedimientos, y de una empresa de servicios con contratos y políticas internas.
Cuando lo que hay son cuatro manuales estables que nadie cambia, un buscador normal alcanza y lo decimos así.
Cómo se empieza
Con un piloto acotado, no con un proyecto de meses: se define un alcance, se conecta a las fuentes reales y se pone a prueba con la propia gente de la organización. Es la única forma honesta de saber si funciona con sus documentos, que es lo único que importa.
killari.ai es de CloudComputing Perú, igual que verifac.pe y anote.pro, y comparte con nuestro trabajo en gestión documental para el Estado la misma obsesión: que cada afirmación tenga detrás un documento que se pueda señalar.
