Considera un asistente propuesto para Odoo Helpdesk que lee un ticket y prepara una respuesta. Revisar ese borrador es una decisión de autorización distinta de permitir que el asistente lo envíe al cliente. El texto puede ser idéntico, pero el envío incorpora un destinatario externo y una comunicación empresarial que no existen en un borrador interno.
Autoriza la acción, no la interfaz. Separa la consulta de información, la redacción de contenido, las propuestas de cambios en registros y los cambios efectivamente aplicados. Mantén el caso de uso limitado a borradores hasta que se hayan demostrado sus permisos de ejecución, reglas de aprobación y gestión de excepciones. Permite la ejecución acotada solo cuando el responsable del proceso acepte las consecuencias y los controles necesarios superen las pruebas.
Empieza por las consecuencias para el negocio
Ask AI y la creación de proyectos a partir de PDF son candidatos útiles para esta evaluación. En su análisis de la hoja de ruta de Odoo, René Passmann describe como líneas propuestas las búsquedas en lenguaje natural sobre información empresarial y la creación de fases y tareas de proyecto a partir de un PDF técnico. También advierte de que la hoja de ruta no garantiza todas las funciones y describe la mayoría de las capacidades de IA comentadas como orientadas a Enterprise.
Considera aquí Ask AI, la redacción en Helpdesk, la creación de proyectos desde PDF y la reasignación de leads en CRM como escenarios propuestos de evaluación, no como funciones verificadas en producción. Antes de encargar un piloto, obtén confirmación de la versión exacta, la edición, la modalidad de alojamiento y las suscripciones necesarias. Que una función esté disponible para Enterprise no demuestra que exista un determinado control de permisos o aprobación.
Para las consultas, define qué registros y empresas puede buscar el solicitante. Para la redacción, añade dónde puede almacenarse el contenido generado y quién puede verlo. Para los cambios propuestos, exige una comparación verificable entre los valores actuales y los sugeridos. Para la ejecución, especifica la operación de escritura o envío permitida y las condiciones que la autorizan. No permitas que el permiso para un paso implique el permiso para el siguiente.
Una propuesta de reasignación de un lead debería mostrar el responsable actual, el responsable sugerido, el lead afectado y el motivo, sin modificar la asignación. Aplicar esa propuesta exige una decisión independiente sobre los leads elegibles, los responsables de destino permitidos y quién aprueba las excepciones. Del mismo modo, el permiso para redactar una respuesta de Helpdesk no debería implicar permiso para enviarla, modificar los destinatarios o adjuntar documentos.
Redacta una especificación de controles por acción
Crea una especificación para cada acción, no una única aprobación denominada «activar IA». El análisis sobre la evaluación de flujos de trabajo con IA en el ERP recomienda identificar registros, acciones e identidad de ejecución, y demostrar el comportamiento con permisos representativos, en lugar de recurrir a una cuenta de administrador sin restricciones. Aplica ese mismo rigor a esta decisión más concreta sobre autorización.
La siguiente matriz es una propuesta de especificación de aceptación. Sus entradas son requisitos que deben definirse y probarse, no afirmaciones sobre controles que Odoo proporcione.
| Dimensión de control | Qué debe recoger la especificación | Evidencia que conviene solicitar |
|---|---|---|
| Datos accesibles | Registros, empresas y adjuntos permitidos, e identidad de ejecución | Pruebas de acceso representativas, incluidos registros denegados y cualquier acceso mediante cuentas de servicio |
| Cambios permitidos | Tipos de registro, campos, operaciones y valores admitidos | Registros anteriores y posteriores que muestren únicamente cambios autorizados |
| Divulgación externa | Datos enviados a proveedores de modelos, destinatarios de mensajes y adjuntos permitidos | Flujo de datos específico de la configuración y condiciones aplicables del proveedor |
| Responsable de aprobación | Rol aprobador, condiciones de aprobación y cambios que la invalidan | Bloqueo de la ejecución sin una aprobación válida de la acción exacta propuesta |
| Evidencia de auditoría | Solicitante, aprobador, identidad de ejecución, destino, valores aprobados y resultado | Una trazabilidad verificable que conecte la solicitud con su resultado real |
| Gestión de excepciones | Condiciones de parada, revisión y reintento, con un responsable de recuperación | Demostración del tratamiento de rechazos, fallos y ejecuciones de resultado incierto |
| Detención de nuevas ejecuciones | Quién puede desactivar la acción y cómo se trata el trabajo pendiente | Una prueba que demuestre que se impiden nuevas ejecuciones no autorizadas |
En Helpdesk, explicita el límite: la acción de borrador puede preparar contenido a partir de información permitida del ticket; la acción de envío requiere aprobar el destinatario, el texto y los adjuntos. Si esos elementos cambian después de la aprobación, exige una nueva revisión. «Una persona puede comprobar la respuesta» no basta si sigue siendo posible enviarla sin esa comprobación.
Para la creación de proyectos desde PDF, distingue entre proponer una estructura de proyecto y crear registros operativos. Pide al responsable del proyecto que apruebe las tareas, la empresa, la vinculación con el cliente y cualquier asignación propuesta antes de la creación. Para la reasignación de leads, una regla de ejecución acotada podría cubrir un conjunto explícitamente definido de leads y responsables elegibles, y derivar el resto a revisión. Son reglas operativas propuestas, no afirmaciones sobre funciones nativas.
Resuelve la divulgación de datos por separado de los permisos de escritura. Identifica el proveedor del modelo y la configuración de la cuenta; después, obtén las condiciones aplicables de conservación, uso para entrenamiento, subencargados del tratamiento y residencia de datos. Un flujo limitado a borradores debe permanecer desactivado si la divulgación de datos que requiere resulta inaceptable.
Haz que los agentes invoquen flujos sujetos a controles
Prioriza una arquitectura en la que el agente interprete una solicitud e invoque un flujo de negocio establecido, en lugar de improvisar cada paso de ejecución. El debate sobre IA empresarial explica esta distinción con una factura: el agente pregunta si debe procesarla y después invoca un flujo ya construido, en vez de intentar realizar el procesamiento por sí mismo. La implicación es situar la autorización y la validación de negocio en una ruta de ejecución verificable, no solo en instrucciones conversacionales.
Para la reasignación de leads, pide al equipo que demuestre la operación que comprueba la elegibilidad, la aprobación y los cambios de campos permitidos antes de escribir. Para un mensaje de Helpdesk, pregunta dónde se comprueban el destinatario y la aprobación. Una negativa bien redactada en el chat no basta: demuestra que la operación subyacente también rechaza una solicitud no autorizada.
La documentación de aprobaciones de MCP Server de TeqStars ofrece un patrón concreto de terceros. Describe un mecanismo configurado en el que una llamada a una herramienta sensible debe convertirse en una solicitud para que una persona la apruebe o rechace en Odoo. Esto ilustra un patrón de implementación, no una garantía nativa de Odoo ni una prueba de que otra integración se comporte igual. Exige que la configuración propuesta demuestre su propio control de aprobación.
Prueba los rechazos antes de permitir la ejecución
Empieza por un ámbito acotado cuyos datos y reglas de proceso estén claros. El debate sobre IA empresarial recomienda comenzar en áreas más precisas y menos desordenadas, y avanzar de forma iterativa. Para la aceptación, prueba los comportamientos prohibidos con el mismo rigor que los satisfactorios:
- Consulta no autorizada: solicita un ticket restringido, un adjunto o un registro de otra empresa. Exige que se deniegue el acceso sin revelar contenido protegido.
- Escrituras no deseadas: solicita un resumen, pero comprueba que el responsable, el estado y los campos ajenos a la solicitud permanezcan sin cambios.
- Aprobación ausente o invalidada: intenta enviar o reasignar sin aprobación y, después, modifica el destinatario o el valor de destino aprobados. Exige que la ejecución se detenga.
- Finalización incierta: interrumpe una acción y vuelve a intentarla. Exige un resultado verificable y una decisión de recuperación antes de reenviar la solicitud.
- Autorización retirada: elimina el acceso o desactiva la acción mientras haya trabajo pendiente. Demuestra qué puede seguir ejecutándose y por qué.
Registra para cada prueba el usuario solicitante, la identidad de ejecución, el rechazo esperado, el resultado real y los registros resultantes. Investiga cualquier permiso más amplio de las cuentas de servicio, en lugar de dar por hecho que las restricciones del solicitante se mantienen durante toda la ejecución. Limita la acción a borradores si fallan los controles de ejecución; desactívala si ni siquiera la consulta o la redacción pueden respetar los límites exigidos.
Antes de activar un caso de uso, pide al responsable del proceso y al responsable de seguridad que den su conformidad a la especificación de controles por acción y a los resultados de las pruebas negativas. Si necesitas ayuda para definir los flujos de Odoo o el trabajo técnico que exige aplicar esos límites, comenta tus requisitos con los consultores funcionales y desarrolladores Odoo de Digiventi.
