Conectar unha IA cun ERP non consiste en darlle as credenciais dun usuario e pedirlle que opere. O ERP contén datos e accións con consecuencias distintas: consultar un pedido, preparar un borrador e modificar unha conta bancaria non poden compartir o mesmo nivel de permiso.
Este artigo propón un contrato de integración para unha tarefa concreta. O axente pode interpretar unha petición e propoñer chamadas; a aplicación valida identidade, datos e límites antes de consultar ou escribir. O exemplo é hipotético e debe adaptarse á API e ás regras do ERP escollido.
Comeza por unha operación, non por todo o ERP
Imaxinemos que un equipo recibe por correo unha consulta sobre unha entrega. O primeiro alcance pode ser localizar o pedido, comprobar o estado e preparar unha resposta. A modificación dunha data de entrega queda fóra ata que existan regras, permisos e aprobación específicos. Así se pode medir unha tarefa completa sen abrir acceso indiscriminado.
Documenta a entrada, os identificadores necesarios, a fonte de verdade e o resultado esperado. Inclúe pedidos inexistentes, duplicados, clientes con nomes parecidos e atrasos na resposta do ERP. Se a aplicación non sabe resolver a identidade do pedido, debe pedir aclaración e deter a operación.
| Ferramenta | Permiso | Saída permitida | Comprobación |
|---|---|---|---|
| Buscar pedido | Lectura dun ámbito autorizado | Identificador e candidatos | Identidade e pertenza do pedido |
| Consultar estado | Lectura do pedido confirmado | Estado e data da fonte | Permiso sobre ese pedido |
| Preparar cambio | Crear proposta, sen escribir no ERP | Campos anteriores e propostos | Regra de negocio e responsable |
| Confirmar cambio | Escritura limitada e aprobada | Resultado e identificador da operación | Aprobación, versión e permiso vixentes |
Da petición á confirmación verificable
A proposta do modelo non é unha orde directa ao ERP.
- Entrada
Correo ou formulario identificado.
- Consulta
API de lectura con identidade e ámbito.
- Proposta
Campos concretos e evidencia.
- Validación
Regras, permisos e versión actual.
- Aprobación
Unha persoa autoriza o cambio exacto.
- Execución
Escritura acoutada e comprobación posterior.
Exemplo de aplicación. Un erro en calquera porta detén a escritura e conserva a vía manual.
A aplicación conserva as credenciais e aplica autorización a cada chamada. O modelo non debe recibir un token xeral nin escoller libremente un endpoint. OWASP sinala que a autorización debe cubrir o obxecto concreto, as súas propiedades e a función solicitada: poder ver un pedido non implica poder modificar todos os seus campos.
Antes de executar, volve ler o estado relevante. Unha aprobación dada sobre a versión anterior do pedido pode deixar de ser válida se outra persoa xa o modificou. A interface de revisión debe mostrar o valor actual, o valor proposto e a razón da proposta; unha aprobación xenérica de «continuar» non chega.
Evita duplicados cando falla a conexión
Un timeout non indica necesariamente que o ERP rexeitase a operación: pode ter gardado o borrador e fallar a resposta. Repetir unha creación á cegas pode xerar dous rexistros. Asigna un identificador estable á operación, consulta se xa existe e define como recuperar o resultado antes de reintentar.
A RFC 9110 distingue os métodos idempotentes e advirte contra reintentos automáticos de peticións non idempotentes sen garantías adicionais. Nunha integración concreta, a clave de idempotencia ou unha busca polo identificador de negocio dependen das capacidades documentadas polo ERP; non se poden supoñer.
- Rexistra o identificador da operación e a relación co pedido, sen copiar datos innecesarios.
- Distingue erro de validación, erro temporal e resultado descoñecido.
- Antes dun reintento de escritura, consulta o estado no ERP.
- Se non podes confirmar o resultado, envía a tarefa a revisión humana.
Webhooks e colas tamén precisan control
Se o ERP ou o correo emite eventos, a aplicación debe verificar a súa autenticidade, tolerar entregas repetidas e tratar a chegada fóra de orde. Un evento anuncia que algo ocorreu; antes de actuar, consulta o rexistro e a súa versión actual. A cola facilita separar recepción e procesamento, pero non substitúe estas comprobacións.
Un documento ou correo pode incluír instrucións para o axente, por exemplo cambiar unha conta ou ignorar unha validación. Ese contido é dato da tarefa, non autoridade. A aplicación mantén os permisos no servidor e rexeita accións que non encaixan no contrato da ferramenta.
Proba o contrato antes de escribir en produción
Comeza cun modo de observación: o sistema consulta, prepara propostas e rexistra o que tería feito, sen modificar o ERP. Compara casos ordinarios con pedidos ambiguos, permisos insuficientes, datos contraditorios, caídas da API e operacións xa executadas. Cada caso debe ter un resultado esperado e accións expresamente prohibidas.
Para ampliar permisos, mide tarefas resoltas con revisión, correccións, duplicados e tempo total. A persoa responsable do ERP debe poder suspender o fluxo, recuperar o estado e volver ao procedemento manual. Cambios de modelo, ferramentas ou API esixen repetir as probas relevantes.
A guía sobre axentes de IA explica cando un modelo debe escoller pasos. A guía de automatización documental trata a lectura de facturas antes de chegar ao ERP. Para deseñar o contrato técnico e as súas excepcións, podes consultar o servizo de integracións.
Do coñecemento ao proceso
Estudemos unha integración concreta
Podemos debuxar as consultas, as escrituras permitidas, os estados de erro e a revisión humana dun proceso antes de conectar o axente ao ERP.
Falemos da integración ↗
