IA en cumplimiento: evidencias rastreables y aprobación

Comience por el objeto de evidencia, no por el chat

El primer elemento del sistema debe ser una evidencia estructurada, no una respuesta textual aislada. Cada registro puede contener el identificador de la fuente, el nombre del archivo, la versión, la fecha de recopilación, el propietario, la ubicación del fragmento, la clasificación de confidencialidad y una afirmación extraída. La respuesta generada por la IA debe apuntar a esos registros, en lugar de sustituir los documentos originales.

Este diseño cambia la pregunta de “¿qué concluyó la IA?” a “¿qué datos respaldan esta afirmación y quién puede impugnarla?”. También permite distinguir entre ausencia de evidencia, conflicto entre documentos y evidencia desactualizada. La aplicación puede almacenar un estado como pendiente, confirmado, rechazado o sustituido, junto con el motivo y la fecha de cada cambio. Esto es diseño de software para investigación y control, no una decisión sobre cumplimiento.

• Defina un esquema de evidencia antes de elegir el modelo o la interfaz.
• Separe el texto original, la extracción realizada por la IA y la decisión del equipo en entidades diferentes.
• Use identificadores estables para las fuentes, las versiones, los fragmentos y las afirmaciones relacionadas.

Fuentes y referencias: [2]

Construya la trazabilidad durante la búsqueda

Los documentos deben incorporarse mediante un flujo de ingesta que conserve el archivo original y produzca metadatos verificables. Después, el sistema puede dividir el contenido en fragmentos consultables y recuperar pasajes relacionados semánticamente. La búsqueda semántica resulta útil cuando la pregunta y el documento utilizan palabras diferentes, pero el resultado todavía debe incluir el identificador del archivo, el fragmento encontrado y sus atributos para que el origen permanezca visible.

Los filtros de atributos ayudan a limitar la búsqueda por período, región, área responsable, idioma o estado del documento. Esta capa es importante porque un pasaje relevante puede ser inadecuado para la pregunta actual. Se recomienda aplicar los filtros antes de generar la síntesis y rechazar las respuestas cuando no exista una fuente suficiente. La aplicación también debe registrar la consulta original, la consulta eventualmente reformulada, los resultados recuperados y la versión del índice utilizada.

El texto externo debe tratarse como datos no confiables, aunque parezca una instrucción. El modelo no debe recibir ese contenido en un contexto privilegiado ni decidir por sí solo qué herramientas pueden utilizarse. Las salidas estructuradas, los campos enumerados y las validaciones de esquema reducen las posibilidades de que el texto importado altere el flujo del sistema, aunque no eliminan todos los riesgos. [1]

• Almacene el hash u otro identificador técnico del archivo para detectar sustituciones silenciosas.
• Muestre al usuario el fragmento utilizado, no solamente el nombre del documento.
• Defina una política explícita para los documentos eliminados, sustituidos o que todavía estén en procesamiento.

Fuentes y referencias: [1][2]

Haga de la aprobación una etapa del producto

La aprobación no debe ser un comentario informal dentro de un cuadro de chat. Cree una cola de casos con el contexto mínimo suficiente: afirmación propuesta, fragmentos de origen, documentos en conflicto, nivel de incertidumbre, historial de cambios y acción solicitada. La persona responsable debe poder confirmar, rechazar, solicitar información adicional o derivar el caso a otra función, siempre con un motivo registrado.

Los permisos deben limitar tanto lo que la IA consulta como lo que cada función puede modificar. Una persona puede validar la clasificación de una fuente, mientras otra puede aprobar la publicación de una síntesis. El sistema debe impedir que una aprobación antigua se reutilice automáticamente después de que cambien la fuente, el prompt, el índice o la regla de extracción. En ese caso, el elemento vuelve a revisión o recibe un estado de desactualización.

Para las acciones que modifican registros, envían comunicaciones o actualizan sistemas externos, use una confirmación explícita y registre la solicitud, los parámetros, el resultado y el usuario responsable de la autorización. La IA puede preparar la acción, pero el software debe controlar la transición de estado. Este límite hace que el flujo sea más predecible sin suponer que una aprobación técnica, por sí sola, resuelva una cuestión organizativa.

• Use estados claros: nuevo, en análisis, en espera de información, aprobado, rechazado y obsoleto.
• Registre quién aprobó, cuándo, con qué versión del material y por qué motivo.
• Separe el permiso para visualizar evidencias del permiso para modificar decisiones.

Fuentes y referencias: [1]

Pruebe toda la cadena, no solamente la respuesta

Una prueba que verifica únicamente si la respuesta parece correcta deja fuera fallos más peligrosos. Evalúe si el sistema recuperó la fuente adecuada, conservó el fragmento, aplicó los filtros correctos, identificó el conflicto, rechazó una instrucción insertada en el documento y envió el caso a la cola adecuada. Cada etapa puede tener sus propios criterios, porque un resultado final plausible puede haberse producido a partir de un origen equivocado.

Prepare un conjunto de casos con documentos actuales, versiones antiguas, fuentes incompletas, textos contradictorios, formatos diferentes y entradas maliciosas. Para cada caso, defina el resultado esperado en términos observables, como el identificador de la fuente, los campos extraídos, la decisión de derivación y el motivo del bloqueo. La evaluación debe repetirse cuando cambie el modelo, el prompt, la división de los documentos, los filtros o la interfaz.

Las métricas automáticas pueden verificar campos y llamadas, pero no deben tratarse como sustitutos de criterios bien definidos. Compare los resultados entre versiones, registre las regresiones y conserve los ejemplos de fallo junto con el motivo del fallo. La práctica recomendada consiste en evaluar de forma temprana y continua, combinando pruebas específicas del flujo con valoraciones sobre relevancia y completitud. [3]

• Pruebe la selección de la fuente, la extracción, la síntesis y la aprobación como puntos separados.
• Incluya casos en los que la respuesta correcta sea “no hay evidencia suficiente”.
• Registre las entradas, las salidas, las fuentes recuperadas y las decisiones para reproducir un fallo.

Fuentes y referencias: [3]

Use un piloto hipotético para elegir la arquitectura

Considere una empresa hipotética que recibe políticas internas, informes de proveedores y registros de capacitación en formatos variados. El primer piloto no necesita responder preguntas abiertas sobre todo el acervo. Puede localizar evidencias para una sola categoría, presentar tres fragmentos relacionados, identificar conflictos de versión y crear un caso para aprobación. Esta delimitación permite observar dónde pierde tiempo el equipo y qué campos son realmente necesarios.

En este escenario, la arquitectura inicial puede utilizar ingesta con metadatos obligatorios, búsqueda híbrida o semántica, extracción en un formato fijo, almacenamiento de evidencias y una cola de aprobación. La síntesis solo se produce después de que los fragmentos pasan por reglas básicas de alcance. Si una fuente no tiene fecha, propietario o versión, el sistema puede clasificarla como incompleta y solicitar un tratamiento específico, en lugar de completar las lagunas mediante inferencias.

La decisión entre un flujo sencillo y un agente con herramientas debe seguir la necesidad real del proceso. Si las etapas son previsibles, un flujo de trabajo con transiciones explícitas suele ser más fácil de probar y explicar. Una mayor autonomía solo tiene sentido cuando existe una tarea que realmente exige una elección dinámica y cuando las pruebas pueden detectar llamadas indebidas. El objetivo del piloto es aprender qué controles necesita el trabajo, no presentar a la IA como árbitro final.

• Elija un solo tipo de evidencia y una sola cola de aprobación para el piloto.
• Defina previamente qué cambios requieren un nuevo análisis del caso.
• Interrumpa la generación cuando la fuente esté ausente, en conflicto o fuera del alcance.

Fuentes y referencias: [1][3]