Inventariar tareas y personas responsables
Enumere qué sistemas utilizan IA, para qué y para quién. Distinga redactar un borrador, recomendar, decidir automáticamente y actuar en otro sistema. Para cada tarea nombre al dueño del proceso, los datos, el mantenimiento técnico y la aprobación de cambios. Un solo recuadro de IA en un diagrama no basta: un modelo puede clasificar correos o tener permiso para enviar un mensaje a clientes. Los riesgos son diferentes. El marco AI RMF de NIST organiza el trabajo en gobernar, mapear, medir y gestionar riesgos; aporta un lenguaje compartido sin exigir un proceso pesado. Mantenga el inventario útil para quienes deciden sobre publicaciones.
Dé a cada flujo una finalidad y un límite. ¿Qué entrada puede recibir, qué salida crear y qué debe entregar a una persona? Indique si utiliza datos personales, materiales sujetos a contrato o información con consecuencias financieras. Especifique qué ocurre si el modelo no está disponible y si existe ruta manual. Documente la decisión de forma comprensible para operaciones. Sin propiedad clara, un error puede perderse entre proveedor del modelo, ingeniería y usuarios. La responsabilidad abarca el resultado del proceso, no solo la disponibilidad de una API. Identifique quién puede suspender la función al aparecer pruebas de daño.
Clasificar el riesgo por las consecuencias de la acción
Evalúe probabilidad e impacto del error en cada automatización. Resumir una reunión interna, redactar una respuesta a un cliente y cambiar datos de pago no pertenecen a la misma clase. Considere si el fallo es visible, reversible y si una persona podrá detectarlo a tiempo. Marque acciones sobre personas, dinero, acceso o divulgación de datos. Verifique por separado requisitos del producto y jurisdicción concretos; una guía técnica general no realiza clasificación jurídica. Un mayor impacto exige pruebas más fuertes, permisos más estrechos y un control humano significativo. Registre quién acepta el riesgo residual tras aplicar esos controles.
Defina las condiciones para aumentar la autonomía. Un borrador puede recibir permiso para guardar una etiqueta interna después de un piloto, pero no necesariamente para enviar mensajes a clientes. No amplíe autoridad solo porque varias demostraciones salieron bien; use mediciones representativas y un plan de excepciones. La clase de riesgo cambia al conectar otra fuente de datos o herramienta. Reevalúela cuando cambie materialmente el flujo. Una tabla breve de tareas, impactos y controles ayuda más que una política larga que nadie consulta al publicar. Repita la revisión tras incidentes y cuando crezca el volumen.
Mantener la autorización fuera del modelo
El modelo no debería decidir por sí mismo si una persona puede leer un documento, cambiar un registro de cliente o iniciar un pago. La aplicación del servidor debe imponer estos controles. Dé a las herramientas el alcance mínimo: lectura de datos seleccionados, borrador y quizá una acción limitada pendiente de aprobación. Separe cuentas y claves de prueba y producción. Cuando cambian roles compruebe que los permisos llegan a índices, conversaciones guardadas y cachés. Iniciar sesión no concede autoridad sobre todos los objetos. La política de acceso debe poder comprobarse con casos concretos de usuarios diferentes. Una respuesta correcta basada en datos ajenos confidenciales sigue siendo una filtración.
Textos, correos y páginas pueden contener instrucciones para desviar la automatización. OWASP describe prompt injection como un riesgo procedente de ese contenido. Trate texto no confiable como datos, no como órdenes. Valide parámetros, destinatarios y límites fuera del modelo antes de ejecutar. Vigile peticiones para enviar información a otro lugar o recuperar material ajeno a la tarea original. Pruebe ataques insertados en fuentes y errores normales del usuario. Un prompt no sustituye permisos restringidos y registro de auditoría. Revise cada herramienta nueva como posible ampliación de lo que alguien podría inducir al sistema a hacer.
Diseñar aprobación humana como control real
Quien aprueba necesita ver propuesta, pruebas, motivo y posibles consecuencias. Un botón de aprobar sin tiempo ni contexto es solo una barrera formal. Decida qué acciones requieren una segunda persona, cuáles puede confirmar el usuario inicial y cuáles pueden ejecutarse automáticamente con seguridad. La aprobación corresponde a una versión exacta de la salida; si el modelo la cambia después hace falta otra decisión. Ofrezca reparación y escalada. Establezca límites para aprobaciones masivas, pues revisar cientos de elementos puede convertir la supervisión en una ficción. Mida si la interfaz permite detectar una sugerencia mala antes de que tenga efecto.
Durante el piloto observe cuántas propuestas se corrigen, rechazan o aprueban sin leer. Una alta tasa de aprobación no demuestra calidad si revisar resulta agotador o las pruebas están ocultas. Pregunte a revisores cuándo dudan y qué información les ayudaría. Si una persona sigue siendo responsable, la interfaz debe permitirle decidir razonablemente. La automatización debe ahorrar trabajo rutinario, no pasar el riesgo a alguien que no puede ver lo que hizo el modelo. Permita registrar por qué se anuló una propuesta y convierta ese caso en prueba futura.
Conservar trazabilidad sin recogerlo todo
Para cada acción importante registre iniciador, versión del flujo y modelo, identificadores de entradas pertinentes, propuesta, aprobación y efecto final. Debe poder explicar por qué ocurrió y cómo corregirlo. No necesita copiar documentos sensibles completos a los registros. Separe diagnósticos operativos de pruebas de auditoría y defina quién puede inspeccionarlos. Ante un error relacione la salida con versiones de prompt, herramientas y fuentes. Cambios de parámetros y permisos pueden importar tanto como el código. Compruebe que alguien ajeno al desarrollo puede reconstruir una decisión de ejemplo con la evidencia conservada.
Establezca conservación según finalidad y normas reales de la organización. Los usuarios deben saber cuándo su texto llega a un proveedor externo y quién puede verlo. Si se usan varios modelos o servicios, documente el trayecto efectivo de datos. Al borrar o corregir una fuente considere si el contenido viejo permanece en una salida o conversación guardada. Los registros de incidentes deben estar disponibles para el equipo responsable y no para todo administrador. Trazabilidad no justifica guardarlo todo para siempre; una buena evidencia selecciona lo necesario para explicar y reparar. Pruebe si la eliminación alcanza registros derivados cuando corresponda.
Medir calidad con escenarios realistas
Prepare casos normales, difíciles y prohibidos. Mida resultado correcto, afirmación sin respaldo, acción improcedente, derivación humana y tiempo de reparación. En clasificación examine errores por categoría; en borradores, exactitud factual e idioma; en acciones autónomas, también destino y parámetros. La media puede ocultar un grupo pequeño de fallos graves. Separe pruebas de ejemplos usados para ajustar y añada errores nuevos regularmente. El perfil NIST para IA generativa enfatiza evaluar riesgos durante todo el ciclo de vida, no solo en una demostración inicial. Acuerde límite de fallo y responsable antes de lanzar para poder detener una expansión deficiente.
Después de publicar siga propuestas aceptadas, correcciones y consecuencias negativas. Registre fuentes ausentes, cambios de comportamiento del modelo y fallos de servicios conectados. Cada medida necesita responsable y umbral de actuación. Si cae la calidad revierta la configuración o restrinja la función, no se limite a marcar un panel en rojo. Busque también rodeos de usuarios que aumenten riesgo, por ejemplo copiar información sensible a una herramienta no aprobada. La gobernanza eficaz debe verse en el trabajo diario. Pregunte si el sistema sigue resolviendo su tarea original y no solo genera cada vez más solicitudes.
Preparar respuesta a incidentes y apagado
Antes de producción ensaye una acción equivocada, exposición de contenido sensible y falta de disponibilidad. Defina quién detiene la automatización, evalúa el impacto e informa a afectados. Debe poderse apagar la IA por separado de la aplicación principal para continuar el proceso manualmente. Conserve evidencia para investigar e impida que la misma acción se repita al reiniciar. Para operaciones importantes prepare compensación. Volver al contenedor anterior no basta si la IA ya cambió datos en otro sistema. Pruebe el interruptor con quienes realmente lo operarán.
Tras un incidente distinga error del modelo, fuente mala, permiso insuficiente, tarea ambigua y equivocación del operador. Cada causa requiere remedio distinto. Añada un caso de regresión, actualice controles y vuelva a aprobar el nivel de autonomía. Un informe debe explicar qué ocurrió y no afirmar que algo similar es imposible. Si el impacto no puede establecerse con confianza, esa incertidumbre también es un hallazgo. Mantenga el plan breve y accesible a quienes están de guardia. Incluya condiciones para reanudar después de completar reparaciones y pruebas.
Introducir cambios mediante decisiones pequeñas
Un modelo, prompt, conector o fuente nuevos pueden cambiar el resultado sin modificar la pantalla. Versione esas piezas y ejecute las pruebas de control antes de publicar. Apruebe por separado una mayor autoridad. Para cada cambio registre beneficio esperado, riesgo nuevo y condición de retorno. Empiece con poco volumen, observe correcciones y amplíe después. Si la función ahorra tiempo solo en algunos casos, permita escoger la ruta adecuada. La meta es un resultado previsible con trabajo razonable, no la mayor autonomía posible. Mantenga visibles las restricciones temporales para que no se conviertan silenciosamente en política permanente.
EXCOIN puede ayudar a diseñar e implementar un flujo concreto, pero no prometer autonomía segura sin conocer datos, proceso y normas aplicables. En cada hito compare tiempo ahorrado, calidad, volumen de correcciones humanas y coste operativo. Si el beneficio no supera la revisión, reduzca la tarea o no implante la automatización. La buena gobernanza permite decidirlo sin perder el proceso original. Propietario claro, medición e interruptor suelen ayudar más que muchas políticas teóricas. Documente la evidencia que justifica continuar o retirar la función.
Lista antes de activar la automatización
Confirme propósito, dueño, flujo de datos, nivel de riesgo, permiso y responsable del resultado. Pruebe entradas incorrectas y hostiles, rechazo de propuesta, interrupción del modelo, acción repetida y continuación manual. Verifique que quien aprueba ve las pruebas relevantes y que los registros explican un resultado concreto. Revise almacenamiento de entradas, acceso a logs, coste y límites del servicio. Indique quién puede apagar la función y cómo se repara una acción ya ejecutada. Solo después considere más autonomía o afirmaciones comerciales sobre ahorro. Adapte la lista al flujo real y no la use como autorización global para toda IA.
Tras el lanzamiento programe revisiones con responsables de proceso, seguridad y operación. Si cambian datos o normas, actualice pruebas y vuelva a evaluar permisos. Los avisos de errores de usuarios necesitan una vía sencilla de reparación. Distinga el éxito de un piloto de la preparación para trabajo rutinario a mayor escala. El resultado real es un proceso rastreable en el que las personas saben cuándo utilizar el modelo, cuándo comprobar la salida y quién decide finalmente. Así la automatización puede crecer sin trasladar riesgos silenciosamente entre equipos. Conserve fecha y resultados de revisión para futuros mantenedores.