Errores de arquitectura de IA que se pagan meses después

Por qué no se ven a tiempo

Porque la demo no los toca. Una demo prueba que el sistema puede hacer algo una vez, en condiciones elegidas.

Lo que revela un error de arquitectura no es el uso: es el cambio. El segundo caso de uso, el segundo agente, el cambio de modelo, la segunda área. Y todo eso llega meses después de la aprobación.

Hay una segunda razón por la que no se ven: el incentivo de quien construye está en entregar, no en el mes ocho.

No es mala fe ni falta de conocimiento. Un proveedor con contrato cerrado y fecha de entrega optimiza para la fecha de entrega, que es lo que se le pidió.

Por eso estos seis puntos hay que pedirlos explícitamente en el pliego. Esperar que aparezcan solos es esperar que alguien trabaje contra su propio incentivo.

1 · Permisos amplios desde el primer día

El más común de todos y el que peor envejece.

Se conecta con una credencial de administrador porque es lo rápido, funciona, y ahí se queda. A los seis meses hay tres procesos que dependen de ese acceso amplio, y restringirlo implica averiguar cuál de los tres se rompe.

Cuándo se paga: en la primera revisión de seguridad, o en el primer incidente.

Cómo se evita: credencial propia por sistema y permiso mínimo desde el día uno, aunque cueste medio día más. El detalle está en seguridad de las integraciones de IA.

2 · Sin frontera escrita

El sistema hace lo que puede hacer, y lo que puede hacer nunca se definió: se fue quedando.

Nadie puede responder qué es lo peor que ese sistema podría hacer sin que nadie lo apruebe, y esa pregunta llega siempre, normalmente desde fuera del equipo.

Cuándo se paga: cuando el sistema hace algo que nadie esperaba y hay que explicar por qué podía hacerlo.

Cómo se evita: la tabla de tres columnas antes de producción, decidida por negocio y no por el equipo técnico.

3 · Todo el contexto metido en el prompt

Es el error que más despacio se manifiesta y el que más cuesta desmontar.

Empieza con instrucciones razonables. Cada caso raro que aparece añade una regla. A los seis meses hay tres páginas de instrucciones donde nadie sabe qué línea sostiene qué comportamiento.

A partir de ahí, cambiar una línea rompe otra cosa, y el equipo deja de tocarlo. El sistema se congela: no porque esté bien, sino porque da miedo.

Hay una señal temprana de este error que se puede vigilar antes de que sea grave: el ritmo al que crece el prompt.

Si cada semana se añade una regla nueva, el sistema está aprendiendo por acumulación en vez de por diseño. A ese ritmo, el punto en que nadie se atreve a tocarlo llega en unos meses.

Cuando se detecta a tiempo, la reorganización cuesta días. Detectado tarde, cuesta rehacer el sistema con el riesgo de perder comportamientos que nadie sabía que estaban ahí.

4 · Sin registro de lo que decidió

Es el error que hace imposible todos los demás arreglos.

Sin registro no se puede reconstruir un caso, no se puede medir la calidad, no se puede detectar que el comportamiento cambió y no se puede aprender nada de los errores.

Cuándo se paga: la primera vez que un cliente reclama por algo de hace tres semanas.

Cómo se evita: cuatro campos desde el día uno. Qué recibió, qué decidió, por qué y qué herramientas usó.

5 · Atado a un proveedor sin darse cuenta

No por contrato, que sería una decisión. Por diseño, que es un accidente.

La lógica de negocio termina mezclada con las particularidades de un proveedor: su formato de respuesta, su forma de manejar errores, sus herramientas propias.

Cuándo se paga: cuando el proveedor sube el precio, deprecia una versión o sale algo mejor.

Cómo se evita: una capa propia entre tu sistema y el proveedor, decidida el primer día. Cuesta poco al principio y es lo que hace viable cambiar de modelo sin perder lo construido.

6 · Construir para el volumen del piloto

Es el error que más sorprende porque el proyecto va bien, y precisamente por eso ocurre.

Se diseña para cien casos al día, funciona, se extiende a otra área y de golpe son mil. Aparecen los límites de frecuencia del proveedor, el costo se multiplica y la latencia se nota.

Cuándo se paga: exactamente cuando el proyecto tiene éxito, que es el peor momento posible.

Cómo se evita: estimar el volumen del mes doce y comprobar contra los límites del proveedor antes de construir, no después.

Tres errores menores que también se pagan

No hunden un proyecto y sí lo encarecen de forma sostenida.

• Usar el modelo más caro para todo. La mayoría de tareas de un sistema no lo necesitan, y repartirlas baja la factura sin que nadie note diferencia.
• Mandar más texto del necesario en cada llamada. Se paga por unidad de texto y casi siempre sobra la mitad.
• No prever qué pasa cuando el proveedor no responde. Sin plan, el sistema falla delante del usuario.

Cómo detectarlos en un sistema que ya está funcionando

Seis preguntas. Media hora. Se pueden hacer sin perfil técnico si alguien técnico está en la sala para responder.

Cada respuesta incómoda es un error de arquitectura vivo. Y todas se corrigen más barato ahora que dentro de seis meses, que es el único argumento que hace falta.

Una recomendación sobre cómo conducir esas seis preguntas: por escrito y con las respuestas anotadas.

Hechas en conversación, las respuestas incómodas se suavizan y la reunión termina con la sensación de que todo está razonablemente bien.

Anotadas, quedan seis frases que alguien tiene que poder defender dentro de seis meses, y eso cambia el nivel de honestidad de las respuestas.