Datos para IA: quién responde por cada fuente

Una empresa conecta su catálogo, su CRM y varias carpetas internas a un asistente. La primera semana todo parece funcionar. Luego alguien pregunta por una condición comercial y recibe una respuesta basada en una presentación antigua. Otra persona consulta el estado de un cliente y el sistema mezcla una nota interna con un registro vigente.

La reacción suele ser revisar el modelo o cambiar el prompt. Antes de hacer eso conviene formular una pregunta más incómoda: ¿quién responde por cada fuente que el sistema está usando?

En una solución de inteligencia artificial aplicada, el dato no es un material anónimo que Tecnología entrega para que el modelo lo interprete. Cada fuente tiene un origen, un propósito, una vigencia y alguien que debe poder explicar si todavía manda. Sin esa responsabilidad, la empresa puede tener muchos documentos y muy poco control.

El dato tiene una historia que la respuesta no muestra

Un asistente puede encontrar una frase correcta en un documento que ya no debería utilizarse. También puede combinar dos registros verdaderos que pertenecen a contextos distintos. La respuesta final oculta parte de esa historia: normalmente muestra una conclusión, no la cadena de decisiones que llevó hasta ella.

Por eso conviene describir cada fuente con algo más que su nombre y ubicación. Como mínimo, el equipo debería poder identificar:

• qué proceso o pregunta cubre;
• quién la publica o mantiene;
• quién autoriza sus cambios;
• desde cuándo aplica y cuándo deja de aplicar;
• a qué clientes, áreas, sedes o contratos se refiere;
• qué fuente reemplazó, si existe una versión anterior;
• qué hacer cuando está incompleta o contradice otra fuente.

No todos esos campos deben vivir en una herramienta sofisticada. Lo importante es que la información exista y que el asistente pueda usarla para escoger, citar o descartar una fuente. Un archivo llamado politica_final_v7.pdf no ofrece suficiente contexto, aunque haya sido creado ayer.

Custodio, dueño y usuario no son la misma persona

En muchos proyectos se dice que "el área" es responsable del dato. Esa frase se vuelve débil cuando aparece un error. Un área puede tener varios equipos, proveedores y niveles de aprobación. Además, quien administra el repositorio no necesariamente decide el contenido.

Pensemos en una tabla de precios. Ventas puede usarla todos los días, Finanzas puede revisar el margen y Tecnología puede integrarla al asistente. Ninguna de esas funciones demuestra por sí sola quién puede aprobar una nueva condición. La empresa debe definir esa autoridad antes de permitir que la IA prepare una cotización o responda a un cliente.

Una asignación útil separa responsabilidades, aunque una misma persona pueda asumir más de una:

• el responsable de negocio define qué significa que el dato sea válido;
• el custodio mantiene la fuente, sus permisos y su ciclo de actualización;
• el usuario autorizado consulta o corrige dentro de su alcance;
• el equipo técnico conserva la conexión y el registro de cambios, pero no inventa la regla de negocio.

Esta división evita un error frecuente: atribuirle a Tecnología la responsabilidad de decidir si una política comercial, una instrucción de soporte o una condición contractual sigue vigente. La plataforma puede detectar que hay dos versiones. No debería decidir cuál tiene autoridad si la organización nunca lo estableció.

Una fuente sin dueño se vuelve una respuesta con dueño difuso

Cuando nadie tiene asignado el mantenimiento, el contenido envejece de forma silenciosa. Un procedimiento permanece en una carpeta porque todavía se puede abrir. Una página interna conserva instrucciones de una campaña anterior. Un proveedor sube un archivo nuevo, pero nadie retira el anterior del índice de búsqueda.

El asistente puede responder con material disponible y la empresa termina discutiendo quién se equivocó. El usuario dirá que preguntó algo razonable. Tecnología mostrará que la integración funcionaba. El área de negocio señalará que el documento estaba guardado. Todos tendrán una parte de razón y nadie tendrá la responsabilidad completa de corregir el origen.

La seguridad y gobernanza de IA debe hacer visible esa cadena. No basta con restringir quién abre una carpeta. También hay que registrar quién puede publicar, retirar, aprobar y revisar la información que gobierna una respuesta.

La responsabilidad debe aparecer en el recorrido de la pregunta

Una buena ficha de fuente no sirve si el flujo de uso la ignora. La consulta debe llevar al sistema a la fuente adecuada y conservar el contexto que permite justificar la respuesta.

Por ejemplo, una pregunta como "¿cuánto cuesta el servicio?" puede requerir el catálogo general. Si el usuario pregunta por el precio acordado para un cliente concreto, el sistema necesita confirmar identidad, contrato y fecha. Si existe una propuesta pendiente de aprobación, no debería convertirla en precio oficial porque contiene una cifra.

La ruta cambia según la intención:

1. La empresa clasifica la pregunta y determina el proceso relacionado.
2. El sistema consulta las fuentes permitidas para ese proceso.
3. La fuente aporta versión, fecha, alcance y responsable.
4. El asistente responde solo si encuentra evidencia suficiente.
5. Si hay conflicto o falta un dato, prepara el caso para la persona que puede resolverlo.

Una automatización de procesos puede ayudar a registrar esa excepción, asignarla y avisar cuando una fuente lleva demasiado tiempo sin revisión. La automatización no reemplaza la autoridad de negocio. Evita que la excepción se pierda en una conversación o dependa de que alguien recuerde enviar un correo.

Las contradicciones son hallazgos, no solo errores de respuesta

Dos documentos pueden ser correctos dentro de su propio contexto. Una política nacional y una instrucción temporal de una sucursal no necesariamente se contradicen; quizá aplican a lugares o fechas diferentes. El problema aparece cuando el sistema no puede distinguir ese alcance.

Cuando detecte una contradicción, el equipo debería conservar las dos fuentes y registrar la pregunta que la reveló. Después debe decidir si:

• una fuente reemplaza a la otra;
• cada una aplica a un contexto distinto;
• falta una regla de prioridad;
• ambas están incompletas y requieren una nueva versión.

Borrar una de ellas para que el asistente deje de mostrar el conflicto puede ocultar la deuda de la organización. La corrección útil explica qué fuente manda y por qué. Si el caso sigue abierto, la respuesta debe decirlo y escalarlo con la evidencia necesaria.

El AI Risk Management Framework de NIST plantea la rendición de cuentas y la transparencia como características de sistemas confiables, y sitúa la gestión del riesgo a lo largo del ciclo de vida. Aunque es un marco voluntario y no sustituye la normativa aplicable, ofrece un lenguaje práctico para preguntar quién decidió, con qué información y bajo qué controles.

En Panamá, el propósito también importa

Cuando las fuentes contienen datos personales, el equipo no debería justificar un acceso amplio solo porque la integración lo hace posible. La Ley 81 de 2019 sobre protección de datos personales y su reglamentación mediante el Decreto Ejecutivo 285 de 2021 ofrecen el marco oficial para revisar finalidades, derechos y responsabilidades del tratamiento.

Para una IA empresarial, esto se traduce en preguntas concretas: ¿qué tarea necesita este campo?, ¿quién debe verlo?, ¿durante cuánto tiempo?, ¿qué ocurre cuando el titular solicita corrección o cancelación?, ¿la fuente se conserva por una obligación real o por costumbre? La respuesta no es un dictamen legal automático. Es una señal de que el diseño debe involucrar a quienes conocen la operación y las obligaciones aplicables.

El responsable del dato también necesita saber qué queda registrado cuando el asistente consulta una fuente. Las entradas, las respuestas, los documentos recuperados y las correcciones pueden contener información que merece un tratamiento definido. Ocultar un dato en la respuesta no significa que nunca haya entrado al sistema.

Un inventario pequeño puede revelar el problema

No hace falta comenzar con toda la empresa. Es más útil escoger un recorrido de riesgo razonable, como responder consultas de servicios, preparar propuestas o orientar solicitudes de soporte. Para cada pregunta frecuente, el equipo puede anotar la fuente esperada, su responsable, la fecha de revisión y la salida cuando falta evidencia.

Después debe probar cambios reales. Se retira una versión antigua, se actualiza una condición, se corrige un campo y se introduce una pregunta ambigua. La revisión no debería limitarse a comprobar si la respuesta suena bien. También debe confirmar que el sistema usa la fuente correcta, muestra el alcance necesario, conserva el motivo de una escalación y deja de consultar lo que ya no aplica.

Las primeras métricas pueden ser sencillas: fuentes sin responsable, documentos sin fecha efectiva, contradicciones abiertas, tiempo para retirar una respuesta vencida y excepciones que regresan sin solución. Esas medidas describen la capacidad de sostener la IA después de la demostración.

La pregunta que debe quedar respondida

Antes de ampliar el acceso del asistente, la empresa debería poder responder quién valida cada fuente, quién autoriza cambios y quién recibe un caso cuando la información no alcanza. Si la respuesta es "el equipo" o "la plataforma", todavía falta una decisión de gobierno.

Los modelos pueden resumir, clasificar y preparar respuestas. La responsabilidad sobre el dato sigue perteneciendo a la organización. Cuando esa responsabilidad está asignada, la IA trabaja con límites comprensibles y los errores pueden corregirse en el lugar correcto. Cuando no lo está, cada respuesta parece un asunto del modelo, aunque el origen haya sido una fuente que nadie se ocupó de mantener.