Odoo 19 a 20: ¿qué debes volver a validar en IA?

Volver

Kevin Riedl

12 minutos de lectura · 5 nov 2026
Última revisión 5 de noviembre de 2026

Siguiente

La base actualizada se abre. El agente responde a una pregunta conocida. El equipo quiere reactivar su automatización anterior. Todavía necesitas demostrar que el flujo usa la configuración prevista, accede a los registros correctos y se detiene donde debe decidir una persona.

Antes de reactivar en Odoo 20 un flujo de IA de Odoo 19, relaciona la configuración anterior con la real de destino, confirma la ruta de solicitudes y facturación, y repite casos de negocio acordados en un entorno aprobado. Registra las rutas desactivadas como evidencia pendiente. Un responsable del proceso debe aceptar el comportamiento antes de reanudarlo.

Investigación revisada: 5 de noviembre de 2026. Este es un método de aceptación propuesto a partir de documentación oficial versionada. No hemos ejecutado una migración de Odoo 19 a 20. No hemos medido el rendimiento de un agente. El ejemplo y el registro descargable siguen sin ejecutarse.

¿Qué cambios documentados requieren una nueva decisión?

Empieza por las diferencias documentadas de configuración y después inspecciona la base actualizada. Las guías indican qué ajustes merecen atención, pero no establecen cómo migrarán tus agentes, credenciales o acciones personalizadas. La comparación entre versiones aporta preguntas; el entorno de destino debe proporcionar evidencia para responderlas.

La guía de agentes de 19.0 describe Topics. La guía de 20.0 describe Skills, y las opciones de estilo de respuesta también difieren. Relaciona los ajustes explícitamente. Una etiqueta conocida o nueva no demuestra que se cumplan los criterios anteriores de aceptación.

La descripción de IA de 20.0 indica que las solicitudes consumen créditos IAP. La página de claves API de 20.0 está en construcción. Esa laguna deja sin demostrar qué ocurre con una configuración antigua concreta de credenciales. Obtén una respuesta actual para la ruta que pretendes operar.

El detalle del presupuesto de créditos de IA de Odoo y de las evidencias de ubicación del procesamiento pertenece a revisiones separadas. Referencia aquí esas decisiones para mantener el expediente de aceptación centrado en el flujo.

¿Qué debe contener el registro antes y después?

Captura la configuración necesaria para explicar un flujo desde su disparador hasta el resultado aceptado. Incluye versiones exactas, instrucciones del agente, herramientas, fuentes, identidad de ejecución y límite de revisión. Registra cambios intencionados y diferencias sin explicar. Una lista de aplicaciones instaladas no demuestra que ese proceso concreto haya sobrevivido a la actualización.

Asigna un identificador estable, como STOCK-NOTE-01, y un responsable de negocio. Registra la compilación o referencia de despliegue real detrás de las etiquetas «19» y «20». Si el origen cambia después de capturarlo, actualiza la referencia antes de compararla con el destino.

No guardes secretos en el registro. Usa una referencia de credencial, propietario de cuenta y fecha de verificación. Conserva una versión aprobada de cada prompt o conjunto de instrucciones y la versión de documentos o datos utilizada en las pruebas. Así podrás explicar diferencias sin copiar datos de producción a una hoja de planificación.

Una entrada útil identifica ajuste anterior, ajuste de destino, motivo, efecto esperado y aprobador. «Cambiado al nuevo valor predeterminado» deja el efecto de negocio sin resolver. «Cambia el estilo; acceso y revisión siguen sujetos a R06-A a R06-C» crea una afirmación que se puede comprobar.

Separa esto de la conciliación de datos. La guía de aceptación y conciliación de migraciones aborda registros y saldos. Este expediente explica si el comportamiento asistido por IA alrededor de esos registros resulta aceptable.

¿Qué deja sin demostrar una base de pruebas neutralizada?

El entorno puede suprimir la ruta que necesitas evaluar. Registra qué disparadores, solicitudes y efectos están desactivados antes de interpretar un resultado. Si una ejecución programada no ocurrió o su ruta de IA no estaba disponible, marca esa parte como no probada y prepara un ejercicio controlado que aporte la evidencia pendiente.

La documentación de bases neutralizadas de Odoo incluye acciones programadas y tokens IAP entre las funciones desactivadas. La lista no es exhaustiva. Nuestra inferencia es concreta: una conversación manual satisfactoria no demuestra la ejecución de una ruta programada o IAP que estaba desactivada.

Antes del ejercicio, declara su aislamiento: datos sintéticos o aprobados, destinos permitidos, referencias de cuenta, límite de gasto, escrituras autorizadas y persona que puede detenerlo. El responsable técnico debe identificar qué controles siguen desactivados y qué ruta específica puede habilitarse o sustituirse de forma segura. La neutralización no prueba el aislamiento de toda integración personalizada.

Distingue los tipos de evidencia. Simular un fallo del proveedor puede mostrar que tu código de derivación reacciona a ese fallo simulado. No demuestra que funcionen una cuenta real, su facturación o una solicitud real. A su vez, una solicitud correcta dice poco sobre el programador, la entrega repetida o la revisión humana. Anota el alcance de cada observación.

Si no puedes preparar una ruta controlada antes de la ventana de actualización, conserva el estado de evidencia pendiente y mantén pausada la automatización afectada. Puedes aceptar otros flujos probados de forma independiente sin dar este por aprobado.

¿Cómo debes repetir las pruebas de un flujo existente?

Define el comportamiento esperado antes de comparar entornos. Reutiliza entradas aprobadas y estables y evalúa ambos resultados con las mismas condiciones sobre registros, autoridad y revisión. La salida antigua es una observación, no una respuesta correcta por definición. Reproducir un error anterior mantendría el defecto.

Imagina un equipo de planificación ficticio que usa un asistente para redactar una nota interna sobre excepciones de existencias. El contrato propuesto es limitado: identificar la versión aprobada de la fuente, describir excepciones respaldadas por ella, dejar explícitas las cantidades desconocidas y enviar la nota a revisión. El asistente no debe cambiar cantidades de inventario. Tampoco debe enviar mensajes fuera del proceso de revisión.

Utiliza tres casos distintos: una excepción clara, una fuente incompleta y una fuente con instrucciones para omitir la revisión. Define el resultado esperado antes de ejecutar cualquiera de las versiones. Una nota fluida que inventa una cantidad falla. Otra redacción puede pasar si las afirmaciones, referencias y estado de revisión cumplen lo acordado.

Prueba también la ruta que falla o se detiene. Decide quién recibe el trabajo pendiente, qué ve el usuario y cómo evitar que «sin respuesta» se interprete como «sin excepciones». Fija estas expectativas con independencia del texto de error que devuelva el producto.

Para las comprobaciones detalladas de escritura, utiliza la guía de pruebas de estados de negocio. El expediente de aceptación debe referenciar esos resultados, sin duplicar cada prueba ni convertirse en otro informe de conciliación.

¿Qué evidencias entran en el registro de aceptación?

Separa observaciones de configuración, casos ejecutados y aprobación del responsable. Cada fila necesaria requiere referencia de origen, referencia de destino, resultado esperado, observación real y revisor. Una fila sin evidencia sigue abierta aunque el resto de la documentación parezca completo. El registro muestra esa diferencia, sin automatizar la decisión de aceptar.

Descarga el registro de ocho áreas de evidencia y sus instrucciones de uso. Todas las filas empiezan en NOT_RUN, con observaciones y aprobaciones vacías. Son comprobaciones propuestas, no resultados de una instalación de Odoo.

Usa PASS solo tras revisar la evidencia, FAIL ante una contradicción observada, BLOCKED si el ejercicio no puede continuar y NOT_RUN antes de realizarlo. Si una fila no aplica, registra N/A con motivo y revisor. Son convenciones propuestas para el equipo, no estados propios de Odoo.

No rellenes las celdas con «igual que antes». Referencia la configuración real, el resultado del caso o la decisión. Si corriges un fallo, conserva la observación original y enlaza la repetición de la prueba, en lugar de borrar el historial con una celda verde.

¿Cuándo puede reanudarse el flujo?

Reanuda el alcance definido cuando las observaciones necesarias respalden el contrato de negocio y su responsable acepte las limitaciones restantes. La falta de evidencia y un defecto observado requieren tratamientos distintos, pero ninguno equivale a aprobar. Si solo se acepta una parte manual, documenta ese modo limitado y deja desactivado el disparador pendiente.

El revisor técnico establece qué se ejecutó y qué cambió. El responsable del proceso decide si el resultado documentado sirve para el trabajo. Ambas decisiones deben identificar versión, ruta y alcance. Aprobar un borrador manual no autoriza una escritura desatendida añadida después.

Acuerda qué hacer si las primeras observaciones de producción contradicen la aceptación. Puede corresponder pausar y usar un procedimiento manual; revertir la base necesita su propio plan probado. Desactivar un agente no revierte automáticamente registros ya modificados. La aceptación debe mantenerse separada de cualquier promesa de restaurar un estado anterior.

¿Qué debes resolver antes de reservar la actualización?

Identifica los flujos de IA de los que depende el equipo, asigna un responsable de aceptación a cada uno y resuelve sus rutas de prueba antes de programar la reactivación. El primer entregable es un registro acotado con lagunas visibles. Permite estimar y revisar trabajo concreto, más allá de la instrucción general de «comprobar la IA».

Empieza por un flujo cuyo resultado sea fácil de inspeccionar. Completa la referencia de origen, la correspondencia de destino y las expectativas. Después determina qué otros flujos comparten configuración y ruta, y cuáles requieren evidencia separada. Compartir infraestructura reduce repetición; una autoridad o efectos distintos siguen necesitando su propia decisión.

El servicio de aseguramiento de calidad de software de Wavect puede ayudar a definir alcance y responsables. La lista de QA antes del lanzamiento aporta contexto de entrega. El caso Twinsoft AI es una referencia separada de trabajo con IA; no demuestra la ejecución de este ejercicio propuesto de Odoo.

Trae el inventario de flujos y las dudas de aceptación. Una revisión útil debe terminar con pruebas identificadas, límites conocidos y una persona responsable de cada decisión de reanudar.