IA

La aplicación IA es el asistente LLM de eYssen para Odoo, diseñado con la seguridad como prioridad. Conecta su base de datos con proveedores de modelos de lenguaje (OpenAI, Anthropic, xAI, Google Gemini, OpenRouter y API compatibles), permite a los usuarios chatear con un asistente fundamentado sobre esta instancia de Odoo, y puede ejecutar agentes autónomos que actúan como compañeros de privilegios reducidos en Conversaciones, el chatter, las actividades y las tareas de proyecto.

Toda operación de datos que solicita el modelo pasa por una única puerta de acceso: el asistente nunca recibe más privilegios de los que ya tiene el usuario (o el usuario del agente) en Odoo, y un administrador puede restringirlo aún más con políticas de acceso de IA, capacidades, reglas de canal y confirmación de escritura.

Peligro

Una IA mal configurada es peligrosa. Un agente de IA con grupos de Odoo amplios, capacidades de escritura abiertas o alcance de canal agent_full puede leer, cambiar o eliminar datos empresariales, enviar contenido a un proveedor de LLM externo y actuar sin supervisión. Lea Seguridad antes de activar capacidades de escritura, vincular usuarios de agente o exponer la IA a solicitantes no fiables. La instalación predeterminada está orientada a la lectura y deniega la escritura; cada privilegio que añada es una decisión deliberada.

Nota

El nombre técnico del módulo es ai (Productividad / IA). Depende de Mail, Web, Project, y de los ayudantes de plantillas/categorías de proyecto de eYssen utilizados para la cola de trabajo de AI Ops.

Qué puede hacer

  • Asistente interactivo — burbuja de chat en la bandeja del sistema y IA ‣ Conversaciones para preguntas y respuestas fundamentadas, búsqueda de esquema, obtención web opcional, ingesta de archivos, habilidades y memoria.

  • Escrituras confirmadas por una persona — propuestas de creación, actualización o eliminación en IA ‣ Propuestas de escritura en lugar de modificaciones silenciosas (configurable).

  • Agentes autónomos — identidades res.users vinculadas opcionalmente, con un supervisor, listas de canales permitidos, límites de capacidad, modo de escritura por tarea (confirmación por defecto; híbrido/automático solo mediante activación explícita), aprobación de escrituras pendientes con un aviso en la bandeja del sistema sobre el registro de negocio, y cancelación solicitada por el supervisor (véase Agentes).

  • Marco de políticas de acceso — permisos y denegaciones por grupo, modelo o campo, por encima de las ACL de Odoo (nunca concede más de los derechos propios del usuario que actúa).

  • Habilidades — paquetes de instrucciones reutilizables (de fábrica y personalizados) activados siempre o bajo demanda.

  • Memoria — memorias duraderas de usuario, agente y empresa, con herramientas de grafo y búsqueda.

  • Supervisión — registros de auditoría, amonestaciones por infracción, bloqueos temporales y un libro de ejecuciones de agentes en el que una ejecución cuyo proceso ha muerto se cierra automáticamente.

  • Personalización opcional de MCP, web e interfaz — herramientas externas, búsqueda web y personalización de esquema/vista solo para administradores, todo controlado por capacidades y desactivado por defecto cuando implica riesgo.

A quién va dirigida esta documentación

Rol

Tareas habituales

Administrador del sistema / de IA

Proveedores, ajustes, políticas, agentes, supervisión

Supervisor de un agente

Aprobar propuestas de escritura, revisar tareas y ejecuciones

Usuario habitual de la IA

Chatear, confirmar sus propias propuestas de escritura, usar la memoria

Seguridad / cumplimiento

Modelo de amenazas, privilegio mínimo, registro de auditoría

Mapa de la documentación

Principios clave de diseño

  1. Se ejecuta como el usuario (o como el usuario del agente) — sin sudo sobre los datos empresariales. Las ACL y las reglas de registro de Odoo siempre se aplican.

  2. La política de IA solo restringe, con una única excepción nombrada — ai.access.rule nunca puede conceder un derecho que el usuario subyacente no tenga ya en Odoo. Dentro de ese límite, una regla que nombra un campo concreto es el único lugar donde una regla abre algo que la puerta rechaza por defecto: un campo que también escribe en otro modelo. Un Allow a nivel de modelo deliberadamente nunca levanta esa restricción — véase Protección de escritura entre modelos.

  3. Las capacidades son interruptores maestros — por ejemplo, Write / Delete / Web / MCP / Customize se entregan desactivadas hasta que un administrador las activa.

  4. Canales denegados por defecto para los agentes — un agente sin una regla de canal coincidente rechaza las direcciones entrantes (MD de Conversaciones, @mención, actividad, asignación).

  5. Doble verificación del supervisor por defecto en las escrituras del agente — cada tarea de agente tiene su propio Modo de escritura (por defecto Requerir siempre confirmación). Por ello, las ejecuciones sin supervisión proponen al supervisor, a menos que esa tarea active explícitamente el modo híbrido o automático para trabajos de confianza y bajo riesgo (por ejemplo, cumplimentar facturas de proveedor en borrador que el playbook nunca contabiliza). El modo de escritura global del chat no controla las ejecuciones de los agentes — véase Modo de escritura de la tarea (solo ejecuciones de agente).

  6. El texto del cliente o del correo es material de trabajo, no una autoridad — las instrucciones en el cuerpo de un ticket no pueden aumentar los privilegios del agente; la clasificación y los límites de capacidad solo restan.

  7. Fundamentación — el asistente no debe inventar modelos, campos o etapas; utiliza herramientas y hechos en vivo del entorno de esta base de datos.

  8. Las ejecuciones se registran — la cancelación es cooperativa y queda registrada, nunca es una interrupción silenciosa: la ejecución se detiene en el siguiente límite de paso y se cierra como fallida con un motivo de cancelación. Una ejecución cuyo proceso ha muerto se cierra mediante una tarea de mantenimiento planificada, que reconstruye su fila del libro a partir del registro de envío cuando este sobrevive.

  9. Un rechazo estructural no es un abuso — la puerta rechaza muchas cosas que el modelo simplemente intentó adivinar (un campo no escribible, un campo que también escribe en otro modelo) sin registrar una infracción ni consumir una amonestación, por lo que una lista de infracciones vacía no es prueba de que no se haya rechazado nada. Las amonestaciones son para límites reales: un campo secreto o privilegiado, una denegación explícita de política, una capacidad desactivada.

Véase también

  • Permisos de acceso — grupos de Odoo y reglas de registro (el suelo bajo cada acción de la IA)

  • Modo de desarrollador (modo de depuración) — necesario para los menús técnicos donde residen los parámetros del sistema de IA y las acciones planificadas

  • Conversaciones — mensajes directos de Conversaciones utilizados por los canales de agente

  • Proyecto — tareas de proyecto y canal de asignación (si la documentación de Proyecto está disponible en su versión)