Cómo diseñar un piloto de IA conectado a datos regulados sin abrir toda la organización

1. Empieza por una sola decisión asistida. No conectes un agente a todos los sistemas para demostrar que “puede hacerlo”. Escoge una tarea frecuente y acotada donde reunir información consuma tiempo pero la decisión final siga en manos de una persona. Puede ser preparar un expediente, comparar versiones de una política o resumir cambios desde la última interacción. Define qué salida se espera y qué evidencia debe acompañarla. El piloto necesita una frontera fácil de explicar: si el sistema entra en un caso distinto, debe detenerse o derivar. Esa precisión simplifica permisos, evaluación y conversación con seguridad.

2. Haz inventario del contexto mínimo. Lista las fuentes que realmente necesita la tarea y los campos indispensables de cada una. Separa información pública, datos internos y datos sensibles. Después pregunta qué puede excluirse. El ejemplo de OpenAI con Epic y fuentes públicas de salud es útil porque trata el contexto como fuentes específicas, no como una masa de texto. Conserva identificadores, versiones y enlaces a registros siempre que el sistema lo permita. Si el agente no puede indicar de qué registro salió un dato relevante, el piloto todavía no tiene suficiente trazabilidad para un entorno regulado.

3. Diseña permisos por habilidad. El usuario que puede leer un expediente no necesariamente debe poder exportarlo, editarlo o compartirlo. Asigna solo los scopes requeridos por la tarea y, si existen diferentes niveles de sensibilidad, crea habilidades separadas. Evita tokens amplios “por comodidad” durante el piloto, porque luego se vuelven dependencia. Registra qué identidad ejecutó la acción y prueba qué ocurre cuando un permiso falta o expira. Un buen piloto demuestra que el agente funciona con autoridad limitada; no que funciona porque recibió acceso de administrador a toda la organización.

4. Exige salida revisable. Define un formato que facilite la revisión humana: resumen, cambios detectados, fuentes consultadas, incertidumbres y próximos pasos sugeridos. Prohíbe que el agente cierre decisiones sensibles por sí solo mientras se valida el caso. Si la salida contiene una cifra, fecha o requisito importante, debe poder rastrearse a la fuente. También conviene guardar un log técnico mínimo de la ejecución sin copiar más datos sensibles de los necesarios. La evidencia permite medir calidad y resolver discrepancias sin volver a reconstruir toda la sesión desde memoria o conversación.

5. Evalúa con casos reales y adversos. Construye un set de situaciones representativas: registros completos, información contradictoria, fuente caída, usuario sin permiso, versión desactualizada y una solicitud fuera del alcance. Mide precisión, seguridad, tiempo de revisión y frecuencia de escalamiento. Los números publicados por un proveedor pueden orientar, pero no sustituyen la evaluación sobre tus datos y tus procesos. Un piloto regulado debe fallar de forma segura. Es mejor que el agente diga “no tengo evidencia suficiente” en un caso límite que produzca una respuesta convincente que nadie pueda verificar.

6. Escala por capas, no por entusiasmo. Cuando la tarea inicial tenga resultados estables, añade una fuente o una capacidad a la vez. Repite pruebas de permisos, trazabilidad y recuperación después de cada expansión. Documenta quién aprueba el cambio y qué riesgo nuevo introduce. La meta no es llegar rápido a “agente autónomo”, sino construir una superficie de autoridad que la organización pueda entender. Si cada capa mantiene el contrato de datos, evidencia y revisión, el piloto se convierte en plataforma. Si se amplía sin ese control, la demo exitosa puede transformarse en un sistema imposible de auditar.