El valor empieza por una tarea concreta
La conversación sobre IA suele empezar con una frase demasiado amplia: «queremos un chatbot» o «necesitamos agentes». No explica a quién ayuda el sistema, qué información recibe ni qué ocurre si responde mal. Comience con una tarea repetible, un responsable y una medida: encontrar el procedimiento interno correcto, clasificar solicitudes o preparar un borrador que revise una persona. Mida el tiempo actual, los errores y los casos en los que faltan datos esenciales.
Después compare búsqueda convencional, automatización mediante reglas y un modelo. La generación de texto puede ayudar cuando la tarea contiene lenguaje variable o combina datos de varios documentos. Si la decisión responde a reglas precisas, puede ser mejor un proceso determinista. Un piloto debe mostrar la diferencia en casos representativos y no solo en unas demostraciones atractivas. El éxito supone mejorar el flujo completo, incluida la revisión humana y las correcciones.
Datos y permisos antes del modelo
La calidad de las respuestas internas depende de los documentos originales. Pueden estar desactualizados, ser contradictorios, duplicados o inaccesibles para quienes los necesitan. Antes de crear un sistema RAG hay que definir quién mantiene cada documento, cómo se actualiza, quién puede acceder y cómo se cita un pasaje concreto. El índice no debe abrir un camino nuevo hacia información prohibida para el usuario. Las pruebas deben incluir preguntas que el sistema debería rechazar.
Los datos sensibles requieren un mapa del flujo: qué se envía al proveedor del modelo, qué entra en los registros, cuánto tiempo se conservan las conversaciones y quién puede leer las respuestas. Un modelo local puede dar mayor control de infraestructura, pero también exige gestionar rendimiento, actualizaciones y seguridad. El lugar de ejecución se elige según datos y necesidades operativas reales, no solo por la etiqueta «privado». Las obligaciones legales dependen del uso concreto y requieren valoración propia.
RAG y calidad de las respuestas
RAG suele combinar la recuperación de materiales pertinentes con la generación de una respuesta. Puede fallar en cada paso: un documento no se indexa, la búsqueda devuelve una versión antigua, un fragmento pierde contexto o el modelo deduce algo que la fuente no respalda. Conviene medir por separado si se encuentra el documento correcto, si las citas son precisas y si la respuesta final resulta útil. Cambiar solo el prompt sin una batería de pruebas equivale a modificar el comportamiento a ciegas.
La batería debe incluir preguntas habituales, casos límite, consultas parecidas con significados distintos y preguntas sin respuesta respaldada. Quienes realizan el trabajo pueden valorar si el resultado ayuda a decidir en su contexto. Un cambio de documentos, modelo o recuperación puede alterar la calidad, por lo que se repiten las pruebas. El marco de gestión de riesgos de IA del NIST ofrece una guía general durante todo el ciclo de vida, no una certificación de una aplicación concreta.
Automatización con límite humano
No toda tarea de IA debe terminar en una acción automática. Un borrador de respuesta, un resumen o una propuesta de derivación pueden ahorrar tiempo y conservar la responsabilidad humana. Si el sistema modifica registros o envía mensajes, hay que definir operaciones permitidas, aprobación, reversión y registro de auditoría. Los permisos de las herramientas no deben superar lo necesario para la tarea. Una excepción debe llegar a una persona en una forma que pueda resolver de verdad.
El texto de documentos, correos y páginas web es una entrada no confiable aunque parezca contener instrucciones. OWASP identifica la inyección de instrucciones como un riesgo de las aplicaciones con modelos de lenguaje. El prompt de sistema no es la única defensa: importan los permisos limitados, separar datos e instrucciones, controlar resultados y confirmar acciones relevantes. El piloto debería incluir entradas maliciosas y otras que confundan sin intención. Sin estas pruebas, una demostración puede parecer un proceso fiable sin serlo.
Piloto y decisión de operar
Un piloto parte de pocas tareas, entradas conocidas, resultados esperados y un coste de error explícito. Decida de antemano cómo compararlo con el procedimiento actual: tiempo ahorrado después de revisar, proporción de respuestas correctas, casos devueltos a personas y coste operativo. Las medias pueden ocultar fallos en situaciones raras pero importantes. Los casos de alto impacto necesitan un control separado o deben quedar fuera de la automatización.
La producción añade versiones del modelo y del prompt, seguimiento de calidad, límite de gasto, respuesta a incidentes y una forma de desactivar la función. Cada cambio debe poder compararse con las pruebas. Si no es posible medir la calidad o nadie responde por el resultado, conviene mantener un modo asistido. Este enfoque también es proporcionado para un proyecto pequeño: menos componentes, responsabilidades claras y un resultado comprobable.