Sistemas internos con IA: qué cambia en la decisión
Cuando el equipo arma solo una pantalla que funciona, la conclusión parece obvia: no hace falta contratar a nadie. Tiene sentido, pero la pregunta se movió. La IA redujo el costo de escribir código, no el de las decisiones que mantienen un sistema en pie: quién puede modificar qué y quién responde cuando el número sale mal. Eso es arquitectura.
¿Por qué esta pregunta volvió a la mesa?
Porque ahora la demostración funciona. Un analista de operaciones abre una herramienta de IA el martes y el jueves muestra una pantalla de pedidos que guarda, lista y filtra. No es una maqueta. Corre.
La encuesta de Stack Overflow de 2025 pone números a lo normal que se volvió: el 84% de quienes respondieron usa o piensa usar IA en el trabajo, y el 51% de los desarrolladores profesionales la usa todos los días.
Después de la demostración viene siempre la misma pregunta. Si la pantalla ya existe, ¿para qué pagar un proyecto?
Qué se abarató y qué no
Se abarató producir código. Pantallas, formularios, informes, rutinas de importación. Esa parte del trabajo pasó de semanas a días.
No se abarató decidir. Un sistema que la empresa usa todos los días depende de respuestas que ninguna herramienta escribe por nadie: cuál es la fuente de verdad de cada dato, quién puede ver y modificar qué, qué pasa con el histórico cuando cambia la regla, quién atiende cuando el proceso se traba un viernes a las seis de la tarde.
El informe DORA de 2025 resume el efecto en una palabra: amplificador. La IA aumenta lo que la organización ya hace bien y lo que ya hace mal. Donde el proceso está definido, la ganancia aparece. Donde nunca se definió, la empresa produce indefinición en mayor volumen y en menos tiempo. El informe lo publica Google Cloud, que vende IA, y aun así el hallazgo contradice la promesa de ganancia automática.
Por qué "casi correcto" es peor que incorrecto en una operación
En la misma encuesta, el 66% de los desarrolladores señala como mayor frustración las respuestas de IA que están casi correctas, y el 45% dice que depurar código generado por IA consume más tiempo. La confianza en la precisión queda en 33%, contra 46% que desconfía. Solo el 3,1% dice confiar mucho.
Lo que está mal se detecta. La pantalla no abre, el cálculo devuelve un valor absurdo, alguien reclama el mismo día. Lo que está casi correcto pasa. En un texto de marketing eso cuesta una revisión. En un sistema que emite documentos, calcula comisiones o libera crédito, el error entra en la base, se propaga por los informes y reaparece meses después, cuando alguien nota que los números nunca cerraron con los de finanzas.
La vara de calidad de un sistema en producción no es la de un prototipo. Un prototipo tiene que convencer. Un sistema tiene que estar bien cuando nadie está mirando.
La sensación de velocidad no alcanza para aprobar un proyecto
METR, una organización de investigación sin fines de lucro, hizo el experimento que faltaba. Dieciséis desarrolladores con experiencia, 246 tareas reales en sus propios repositorios, sorteo entre usar y no usar IA en cada tarea. Antes de empezar, previeron una mejora del 24%. Después de trabajar, dijeron que habían ganado un 20%. La medición mostró lo contrario: con IA tardaron 19% más.
El dato es de principios de 2025 y la propia METR lo considera vencido. En febrero de 2026 publicó la continuación, con 57 desarrolladores y más de 800 tareas, que apunta a una ganancia de velocidad, y explicó por qué confía poco en su propio número: mucha gente se negó a participar para no trabajar sin IA, y entre el 30% y el 50% de los participantes dejó de enviar justamente las tareas donde la IA más ayudaría.
La conclusión útil no es que la IA estorbe. Es que la percepción de velocidad no es evidencia, ni siquiera cuando viene de profesionales con experiencia midiéndose a sí mismos. Si la decisión de construir en casa se apoya en la impresión de que ahora es rápido, se apoya en nada.
Un ejemplo, y es una hipótesis
Una distribuidora de treinta personas y unos 3 millones de euros de facturación anual. El analista de operaciones arma con IA una pantalla de pedidos en una semana. Funciona. El equipo la adopta, la hoja de cálculo desaparece, todos celebran.
Al tercer mes pasan tres cosas a la vez. La tabla de precios se edita en dos lugares, porque nadie decidió cuál manda. Un cliente reclama por un pedido aprobado fuera del límite de autorización y no hay registro de quién lo aprobó. La integración con el ERP es una exportación manual que el analista hace cada viernes, y se fue de vacaciones.
No se rompió nada. La operación simplemente volvió a depender de una persona, que era el problema que el sistema debía resolver. El escenario y los números de arriba son una hipótesis de trabajo, no la medición de un cliente.
Qué cambia en la decisión de construir o contratar
El criterio de comprar o construir sigue siendo el de siempre: lo que es commodity se compra, lo que diferencia a la operación se construye. Lo que cambió es qué está contratando la empresa cuando contrata.
Antes contrataba capacidad de producir software. Hoy la producción es la parte más accesible del paquete. Lo que se contrata es la responsabilidad por las decisiones que tienen que sobrevivir al entusiasmo del primer mes, y por quién atiende cuando fallan.
Antes de decidir, responde por escrito:
- ¿Cuál es la fuente de verdad de cada dato que toca este sistema, y quién tiene autoridad para cambiarla?
- ¿Quién puede ver y modificar qué, y qué queda registrado cuando alguien modifica?
- Cuando cambie la regla de negocio, y va a cambiar, ¿quién la cambia, en cuánto tiempo y contra qué prueba?
- Si la persona que lo construyó se va la semana que viene, ¿qué queda en la empresa además de lo que está corriendo?
Si el equipo responde las cuatro, construir en casa con apoyo de IA es un camino razonable. Si no las responde, la IA está acelerando la parte que nunca fue el cuello de botella.
Preguntas frecuentes
Sin equipo técnico, ¿se puede mantener un sistema construido con IA?
Se puede, si las reglas están fuera de la cabeza de quien lo construyó. Eso significa modelo de datos documentado, permisos definidos, ambiente de prueba y un procedimiento escrito para cambios. Sin eso, la empresa tiene un sistema en producción con un único proveedor interno, y ese proveedor se toma vacaciones.
¿Es seguro el sistema que el equipo armó con IA?
La seguridad no es una propiedad de la herramienta, es resultado de decisiones: quién entra, qué ve cada perfil, qué queda registrado y qué pasa cuando alguien deja la empresa. Una pantalla generada en dos días rara vez tiene esas decisiones tomadas, porque no se notan mientras todo funciona. Conviene auditarla antes de meter ahí datos de clientes.
¿Vale la pena pagar por arquitectura si la IA ya entrega la pantalla?
La pantalla es la parte visible y la más barata de rehacer. Lo caro es migrar datos mal modelados, reconstruir un histórico que nadie guardó y destrabar una integración que nadie diseñó. En el rescate de la plataforma de Colo Saúde, que heredamos funcionando, el primer proyecto fue una auditoría de seguridad y un ajuste de rendimiento, antes de cualquier funcionalidad nueva; hoy la misma plataforma migra a otra base tecnológica. La arquitectura decide si dentro de dos años evolucionas el sistema o empiezas de nuevo.
El siguiente paso
Si tu equipo ya construyó algo con IA y la duda es qué parte de eso merece convertirse en sistema, el Diagnóstico de Arquitectura Operacional es una conversación de 30 minutos sobre la operación, antes de cualquier propuesta técnica: agenda la conversación.
Cases relacionados
¿Reconociste tu operación en este artículo?
Agenda el Diagnóstico de Arquitectura Operacional: 30 minutos para mapear dónde está el cuello de botella de tu operación. Sin propuesta en la primera conversación.
Agendar diagnóstico