Un sistema puede registrar una venta, mostrar un inventario y generar un reporte sin estar preparado para operar una empresa. La demostración acredita que un recorrido ocurrió. Falta saber qué pasa cuando dos personas actúan al mismo tiempo, una integración falla o alguien intenta consultar datos que no le corresponden.
La confianza ciega aparece cuando la explicación de la herramienta ocupa el lugar de esas comprobaciones. El problema puede presentarse con cualquier proveedor de IA y también con software escrito enteramente por personas. Utilizar un modelo para desarrollar es una decisión de trabajo; aceptar un sistema empresarial exige evidencia sobre su comportamiento.
El pedido que se cobró dos veces
Pensemos en un caso hipotético: una empresa encarga un pequeño ERP que reúne pedidos, almacén y pagos. El equipo genera una primera versión con IA. El flujo normal funciona: se crea el pedido, se descuenta inventario y se solicita el cobro. Todos los botones responden.
Después, el servicio de pagos tarda en contestar. El operador vuelve a intentar. Si el diseño no distingue entre una operación nueva y el reintento de la misma operación, podría solicitar un segundo cobro. La pantalla inicial no permite saber si se contempló ese caso. Tampoco lo resuelve que el asistente asegure haber seguido buenas prácticas.
Una revisión útil convierte la duda en un criterio: reenviar la misma solicitud no debe producir un segundo efecto económico. Luego comprueba el recorrido, incluidos los fallos de comunicación. El criterio pertenece a la operación de la empresa; no depende de quién escribió el código ni de cómo se llamó el modelo.
El mismo ejercicio puede hacerse con una devolución parcial, una cancelación después del cierre o dos ventas de la última unidad disponible. Son ejemplos de preguntas que deben resolverse con el dueño del proceso. No afirmamos que todos los sistemas generados fallen en ellas; señalamos qué tendría que demostrarse para aceptarlos.
La confianza y la calidad pueden separarse
Un estudio publicado en ACM CCS 2023, de Perry y colaboradores, comparó tareas de seguridad con y sin un asistente basado en codex-davinci-002. Encontró código menos seguro en el grupo con asistencia y mayor confianza de ese grupo en su seguridad. Es evidencia de una combinación preocupante en aquel experimento, no una tasa de fallas aplicable a modelos de 2026 ni una comparación entre proveedores actuales. Estudio original.
La consecuencia para quien compra software es práctica: preguntar «¿se revisó?» resulta insuficiente si la respuesta consiste en pedir al mismo asistente que confirme su propio trabajo. Una segunda revisión con IA puede ayudar, pero no garantiza independencia de criterios. Los casos de aceptación deben proceder de requisitos, riesgos y resultados esperados definidos fuera del código que se evalúa.
El mantenimiento pone a prueba lo que la demostración no muestra
SWE-Milestone evalúa agentes que realizan secuencias de cambios sobre repositorios y continúan trabajando sobre sus propias modificaciones. En la versión de julio de 2026, los autores reportan dificultades para conservar funcionalidades anteriores y evitar que los errores se propaguen entre tareas. Esa evaluación aporta una pregunta relevante: ¿el sistema sigue funcionando después de varias entregas? Investigación original, versión 4.
Sus resultados corresponden al entorno evaluado. El conjunto depende de proyectos con pruebas ejecutables y selecciona cambios con dependencias, lo que puede subrepresentar mantenimiento independiente. No establece una tasa de fracaso de los ERP empresariales ni demuestra que todos los agentes fallen igual.
Como criterio de aceptación, conviene pedir pruebas de regresión: comprobaciones de que las funciones anteriores siguen operando después de cada cambio. En el ejemplo del pedido, incorporar devoluciones no debería romper la protección contra cobros duplicados. La revisión debe acompañar la evolución del sistema.
Lo empresarial está en los límites y las excepciones
Un ERP concentra decisiones de acceso, registros y acciones que pueden afectar dinero o continuidad. La evaluación necesita distinguir, al menos, cuatro preguntas:
- Autorización: ¿quién puede consultar, aprobar, cancelar y exportar? Ocultar un botón no prueba que la operación esté protegida en el servidor.
- Consistencia: ¿qué ocurre si sólo se completa una parte del proceso o si llega la misma instrucción dos veces?
- Trazabilidad: ¿se puede reconstruir quién cambió un dato, qué cambió y por qué?
- Recuperación: ¿qué procedimiento permite volver a operar después de un error y qué información podría perderse?
Estos son criterios editoriales para orientar la evaluación, no una certificación ni una lista exhaustiva. El estándar OWASP ASVS ofrece requisitos verificables para aplicaciones y servicios web, útiles para convertir expectativas de seguridad en revisiones concretas. Citarlo en una propuesta no acredita haberlo aplicado. OWASP ASVS.
El marco SSDF de NIST también trata la seguridad como un conjunto de prácticas integrado al ciclo de desarrollo. Su propósito incluye reducir vulnerabilidades, mitigar su impacto y atender causas de recurrencia. Adoptar un asistente de programación no elimina ese trabajo. NIST SP 800-218.
Dos riesgos distintos: generar software y darle autoridad a un agente
Un programa elaborado con ayuda de IA puede operar después sin consultar ningún modelo. En cambio, un agente conectado al ERP podría interpretar textos y ejecutar acciones durante la operación. Evaluarlos como si fueran el mismo caso deja preguntas sin responder.
En el primero, hay que revisar el software producido. En el segundo, además debe definirse qué puede ordenar el agente, qué información interpreta como datos y qué acciones requieren una autorización específica. Como criterio de diseño, un texto recibido de un tercero no debería adquirir por sí mismo autoridad para modificar cuentas, pagar facturas o exportar información.
La rapidez para generar una integración no decide esos permisos. Los determina la empresa y debe poder verificarlos. Dar acceso amplio «para que el agente no se atore» puede convertir una limitación de la demostración en una exposición operativa.
Qué evidencia pedir antes de ponerlo a trabajar
Una entrega revisable debe mostrar el alcance acordado, los escenarios comprobados y los que siguen pendientes. Para el ejemplo del pedido, interesa ver el reintento, la cancelación, el rechazo de acceso y el comportamiento ante una caída. También debe quedar claro quién mantendrá el sistema y cómo se recuperarán los datos.
No es necesario inmovilizar todo el proyecto hasta probar cualquier situación imaginable. Puede limitarse la primera etapa a un proceso concreto, con usuarios y efectos acotados. Lo que debe evitarse es llamar «ERP empresarial terminado» a un prototipo cuya única evidencia sea una presentación exitosa.
Acinsoft ofrece perfilamiento y desarrollo por etapas. Para un sistema de este tipo, la conversación útil comienza con el proceso, sus excepciones y los resultados que debe demostrar cada entrega. Así el alcance se puede revisar antes de depender de él para operar.
La pregunta decisiva al recibir software es quién puede explicar sus límites y mostrar cómo se comprobaron. La IA puede ayudar a construirlo y revisarlo. La aceptación de lo que va a hacer con la empresa necesita un responsable y pruebas concretas.