Supervisión¶
Los administradores auditan el uso de la IA en .
Registros¶
(ai.log)
Cada evento significativo de chat/herramienta puede generar una fila de registro: usuario, empresa, herramienta, modelo, éxito/fallo, si se usó sudo (debería ser falso para las operaciones de negocio), tiempos y una carga útil opcional.
En producción, prefiera el nivel de registro Metadata only.
Los registros con carga útil completa pueden contener datos personales y secretos pegados por los usuarios; restrinja el acceso y la retención en consecuencia.
Los registros se conservan para auditoría; los pasos de las ejecuciones tienen un ajuste de retención independiente.
Infracciones¶
Los eventos relevantes para la seguridad (patrones bloqueados, denegaciones de canal, abusos de política, etc.) generan registros de infracción. Las sanciones acumuladas dentro de la ventana configurada provocan una suspensión temporal.
Revise las infracciones para:
detectar intentos de inyección de prompts;
encontrar audiencias de canal mal configuradas (ruido de denegaciones);
detectar usuarios que sondean la eliminación/escritura sin tener la capacidad.
Importante
No todos los rechazos aparecen aquí. Los límites estructurales a nivel de campo (un campo que también escribe en otro modelo, o un campo no escribible o no almacenado) no registran ninguna infracción ni generan una sanción, por lo que una lista de Infracciones vacía no es prueba de que no se haya rechazado nada. Una capacidad deshabilitada es un caso distinto: ese sí es un límite sancionable y sí aparece aquí. Consulte el principio 9 en IA para saber qué límites generan sanción, y Protección de escritura entre modelos para los límites de campo.
Busque la evidencia de ese tipo de rechazo en otros tres lugares:
la conversación del usuario que actuó, donde el asistente informa del rechazo e indica el modelo y los campos que no se le permitió escribir;
la pestaña Pasos de la ejecución, en el caso de un agente: la llamada a la herramienta queda registrada con Veredicto del control en denied y el mensaje de rechazo;
el registro del servidor de Odoo, para un rechazo dentro de una carga útil one2many o many2many: el modelo y el campo anidados quedan registrados ahí y en ningún otro lugar de la interfaz, así que pida a quien administre su servidor que los consulte; ahí se indica la regla a nivel de campo que lo habilitaría.
no lo mostrará: ai.log registra las llamadas al proveedor y las escrituras que realmente se aplicaron.
Suspensiones de usuario¶
Suspende temporalmente el uso de la IA para un usuario. El control verifica las suspensiones primero, antes de cualquier trabajo costoso de LLM o de triaje; esto interrumpe la iteración de ataques adaptativos.
Cuando se emite automáticamente, la duración proviene de Ajustes (Minutos de suspensión de IA).
Los administradores pueden gestionar las suspensiones manualmente.
Por diseño, los AI Administrators/Ajustes se consideran exentos de suspensión (son quienes administran los propios rieles); otra razón más por la que los usuarios agente nunca deben ser administradores de IA.
Tareas y ejecuciones de agente¶
Para el trabajo autónomo, supervise también:
Revise los pasos fallidos, los errores de herramientas y los vínculos de escritura pendientes. Los registros de pasos se pueden purgar transcurrido el valor de Retención de pasos de ejecución (días); conserve suficiente historial para poder investigar incidentes.
Tipos de fallo¶
No existe un estado Cancelada ni un estado Recolectada. Cada una de las siguientes ejecuciones aparece simplemente como Fallida en la lista, y es el campo Tipo de fallo del formulario de la ejecución el que permite diferenciarlas. No es una columna y no se incluye ningún filtro para él, así que añada un filtro personalizado o una agrupación personalizada por Tipo de fallo en antes de intentar observar una población. Cada uno de los tres casos siguientes también deja una nota en el chatter de la tarea.
reaped_stuck: ningún worker llegó a finalizar la ejecución (reinicio, terminación por falta de memoria, expulsión del pod) y el recolector la cerró. Una población recurrente apunta a reinicios del servidor o a una tarea que supera su límite de tiempo. Una ejecución recolectada deliberadamente no cuenta para la desactivación automática de la tarea, porque el recolector funciona fuera del despachador: nada archivará una tarea cuyo worker sigue muriendo, así que esta población es la única señal que existe y hay que actuar sobre ella.cancelled: una ejecución que estaba realmente en curso cuando se detuvo a petición mediante Solicitar cancelación. Los pasos que la ejecución sí llegó a ejecutar permanecen en su pestaña Pasos, pero su respuesta registra la cancelación en lugar de una respuesta parcial, y cualquier propuesta de escritura que ya hubiera abierto se cancela junto con ella, de modo que no queda nada por aprobar. Una cancelación es neutra para la racha de fallos de la tarea: ni cuenta ni la reinicia.triage_denied: la comprobación previa a la ejecución rechazó la instrucción permanente de la tarea, por lo que el agente nunca llegó a iniciarse. A diferencia de los otros dos, este sí cuenta para la desactivación automática: cinco fallos consecutivos, con el primero de ellos de más de una semana de antigüedad, archivan la tarea. Una ráfaga normalmente significa una instrucción permanente mal redactada o una interrupción del proveedor de triaje, que falla de forma cerrada.
Otros dos valores corresponden a ejecuciones que quedaron a la espera de aprobación: waiting_approval_expired (nadie respondió a tiempo) y waiting_approval_empty (la ejecución se liberó porque no quedaba ninguna propuesta que esperar, y ninguna de ellas se había aplicado; esto es también lo que se ve cuando un supervisor cancela una ejecución que estaba a la espera de aprobación en lugar de estar en curso). Un fallo ordinario dentro de una ejecución registra en su lugar el nombre de la clase de la excepción.
Consulte Ejecuciones cuyo proceso ha muerto y Detener una ejecución para conocer los mecanismos que hay detrás, y Configuración para los parámetros y las acciones planificadas que los controlan.
Cola de propuestas de escritura¶
es a la vez una herramienta para el usuario y una superficie de control: una acumulación de propuestas de agente pendientes significa que los supervisores necesitan más capacidad, o que el agente es demasiado agresivo.
Importante
El valor de Vigencia de la propuesta de escritura del agente (minutos) solo se aplica mientras la ejecución que propone sigue abierta. Una vez que esa ejecución ha terminado (lo más habitual, una ejecución que superó su límite de tiempo y se cerró como Tiempo agotado), sus propuestas pendientes caducan en el siguiente paso de la acción planificada AI: Expire pending writes, cada 15 minutos, porque ya no queda nadie que lleve de vuelta el resultado. Esa purga se ejecuta sea cual sea el valor configurado para la vigencia, 0 incluido.
Por eso, revise cuanto antes las propuestas de las ejecuciones fallidas y con tiempo agotado; no espere a volver sobre ellas al día siguiente.
Ritmos operativos¶
Diario (producción temprana)
Abra las infracciones y los bloqueos.
Cuente las propuestas de agente pendientes cuya ejecución sigue abierta y resuélvalas el mismo día; una vez que una ejecución ha terminado, sus propuestas se purgan en lugar de esperar.
Semanal
Revise una muestra de conversaciones completas en busca de errores de calidad y de tratamiento de datos.
Revise las nuevas reglas de acceso y los cambios de capacidades (control de cambios).
Después de cualquier incidente
Cambie el nivel de registro solo durante el tiempo necesario.
Exporte los registros relevantes y, después, vuelva al modo de solo metadatos.
Rote las claves API del proveedor si se sospecha una filtración.
Vuelva a leer la lista de comprobación de Seguridad con el equipo responsable.