Arquitectura
Elige la herramienta que tu equipo puede sostener, no la que encabeza la lista.
Durante una gran migración de plataforma elegimos Keycloak para el inicio de sesión único. En el papel era una herramienta sólida, pero era nueva para el equipo y estaba construida sobre un stack que no conocíamos, y esa parte del trabajo tomó seis veces más de lo planeado. Esto fue lo que salió mal, la matriz de evaluación que usamos después y cómo la IA cambia la decisión hoy, incluido cuándo construir con IA y cómo elegir las propias herramientas de IA.
Para sistemas críticos como la autenticación, evalúa cada opción según qué tanto la conoce el equipo, su documentación, su soporte y la carga operativa, no solo por sus funcionalidades. Haz una prueba de concepto corta y con tiempo límite antes de comprometerte. La IA facilita aprender herramientas desconocidas y abarata mucho construir las propias, pero no elimina la necesidad de que alguien sea dueño de la herramienta en producción. Y las propias herramientas de IA merecen la misma matriz.
Qué pasó
En Fincaraiz estábamos migrando un monolito ASP.NET heredado a microservicios con Django y React, para una plataforma con más de 5 millones de visitas al mes. El sistema viejo y el nuevo tenían que funcionar en paralelo, así que necesitábamos una sola capa de identidad que ambos pudieran compartir. Keycloak era una elección razonable: código abierto, completo y muy usado para inicio de sesión único.
El problema era de encaje, no de calidad. Keycloak era nuevo para el equipo y está construido en Java, que estaba fuera de nuestras habilidades principales. Cuando aparecieron los problemas de integración, nadie podía revisar su funcionamiento interno con confianza, y la documentación tenía vacíos para nuestra configuración exacta. Cada problema se volvía una investigación. Esa parte del proyecto tomó seis veces más de lo estimado.
Por qué pasó
Evaluamos la herramienta, no el encaje. La comparación de funcionalidades fue minuciosa. Lo que no preguntamos fue: cuando esto falle con tráfico real, ¿quién del equipo puede arreglarlo, cuánto le tomará y dónde buscará respuestas?
Una herramienta vale lo que vale la capacidad de tu equipo para operarla cuando falla.
La matriz que usamos ahora
Después de una sesión abierta de lecciones aprendidas, agregamos un paso de evaluación para cualquier herramienta crítica. Cada opción recibe una calificación simple de 1 a 5 en estas preguntas:
| Criterio | La pregunta |
|---|---|
| Encaje con el stack | ¿Está construida en un lenguaje y una plataforma que el equipo ya conoce? |
| Experiencia del equipo | ¿Alguien del equipo la ha operado en producción? |
| Documentación | ¿La documentación cubre nuestro caso exacto, con ejemplos que funcionan? |
| Soporte | ¿Hay una comunidad activa, soporte pago o ambos? ¿Qué tan rápido se responden los problemas? |
| Carga operativa | ¿Quién la parcha, la actualiza y la monitorea, y cuánto tiempo toma cada mes? |
| Esfuerzo de integración | ¿Cuánto código a la medida necesita para funcionar con nuestros sistemas? |
| Encaje con la IA | ¿Qué tan bien la conocen los asistentes de IA? ¿Es muy usada o de código abierto, con documentación pública clara, o incluso con un servidor MCP al que puedan conectarse nuestros asistentes? |
| Exposición de datos | ¿Qué datos enviaría la herramienta, o las funciones de IA que trae incorporadas, fuera de nuestros sistemas, y tenemos permiso para enviarlos? |
Una herramienta con puntaje bajo en encaje y experiencia del equipo todavía puede ganar, pero solo si el plan incluye el tiempo y la formación para aprenderla, y un responsable con nombre propio.
Las dos últimas filas no existían cuando elegimos Keycloak. El encaje con la IA importa porque hoy un equipo aprende una herramienta nueva en parte a través de sus asistentes: una herramienta muy usada y con buena documentación pública recibe ayuda precisa, mientras que una poco común recibe suposiciones dichas con seguridad. La exposición de datos importa porque cada vez más herramientas traen funciones de IA que envían tus datos a un proveedor de modelos, a veces activadas por defecto.
Construir, alojar o comprar
En el caso de la identidad, las opciones hoy se dividen en dos grupos, y la elección correcta depende tanto de tu equipo como de tus requisitos:
- Servicios de identidad administrados como Auth0, Okta, AWS Cognito o Microsoft Entra ID. Cambias algo de flexibilidad y una factura mensual por mucho menos que operar.
- Código abierto autoalojado como Keycloak. Más control y sin licencia por usuario, pero tu equipo lo opera, lo actualiza y lo asegura. Keycloak se ha vuelto más fácil de operar en versiones recientes, pero la pregunta de quién es el dueño no desaparece.
En la práctica, el factor decisivo es la responsabilidad operativa. Autoalojar un proveedor de identidad significa asumir sus objetivos de disponibilidad y turnos de guardia, los parches de seguridad y la respuesta a vulnerabilidades (CVE), las actualizaciones de versión, los respaldos de la base de datos y la rotación de las llaves de firma. Si el equipo no puede comprometerse con eso, un proveedor administrado es la decisión de arquitectura más segura.
Cómo cambian la decisión los asistentes de IA
Si enfrentáramos la misma decisión hoy, las herramientas de IA ayudarían en tres frentes y dejarían un problema intacto.
- Aprender un stack desconocido es más rápido. Asistentes como Claude Code, Cursor o GitHub Copilot pueden explicar un código en Java que no conoces, guiarte por la configuración y escribir un primer borrador del código de integración. La penalidad de "no conocemos este lenguaje" es menor que antes.
- Las pruebas de concepto son más baratas. Un prototipo funcional muchas veces se puede construir en días en lugar de semanas, así que no hay excusa para saltárselo con una herramienta crítica.
- Los vacíos de documentación son más fáciles de cubrir. Un asistente puede leer el código fuente y el registro de incidencias cuando la documentación se queda corta.
- Los agentes pueden hacer la primera ronda de la evaluación. Los agentes de programación con IA ya pueden instalar una herramienta en un entorno aislado, configurarla, escribir pruebas de integración y reportar qué falló, muchas veces en una tarde. Eso hace realista una prueba de concepto pequeña sobre dos o tres opciones en lugar de una.
- Pero la responsabilidad sigue siendo humana. La IA puede ayudarte a configurar una herramienta. No puede estar de guardia por ella, y en configuraciones poco comunes puede equivocarse con total seguridad. En sistemas críticos para la seguridad, cada cambio sugerido por IA necesita la revisión de alguien que lo entienda.
Una cuarta opción: construirla con IA
Construir, alojar o comprar tenía un sesgo evidente: construir era caro, así que se compraba o se autoalojaba. Los asistentes de programación con IA cambiaron eso. Una herramienta interna pequeña, una integración o una pantalla de administración que antes tomaba semanas ahora se puede generar en días.
Eso hace tentador construir, y a veces es lo correcto. Pero el código generado tiene el mismo dueño que el código escrito a mano: tú. Alguien tiene que entenderlo, probarlo, parcharlo y mantenerlo funcionando cuando la persona que escribió el prompt ya no esté.
Mi regla general:
| Tipo de sistema | ¿Construirlo con IA? |
|---|---|
| Herramientas internas pequeñas, scripts, pantallas de administración, integraciones puntuales | Muchas veces sí. Barato de construir, de bajo riesgo y fácil de reemplazar. |
| Funcionalidades centrales del producto que el equipo hará evolucionar durante años | Sí, si el equipo revisa y entiende cada cambio. |
| Infraestructura crítica para la seguridad: autenticación, pagos, cifrado | No. Usa un producto o servicio probado. Que sea barato de generar no lo hace seguro de mantener. |
La identidad está en la última fila. La IA habría hecho más rápida nuestra integración con Keycloak. No habría hecho que escribir nuestro propio proveedor de identidad fuera una buena idea.
Las herramientas de IA también necesitan una matriz
El mismo error que cometimos con Keycloak es fácil de repetir con la propia IA: elegir un modelo, un asistente o una plataforma de agentes por una demostración, sin preguntar quién se hará responsable. La matriz anterior sigue aplicando, con algunas preguntas más:
- Evaluaciones. ¿Podemos medir si funciona en nuestras tareas reales, con un conjunto de pruebas, y no solo en una demostración?
- Costo a escala. ¿Cuánto cuesta por uso cuando todo el equipo, o cada cliente, lo usa todos los días?
- Ritmo de cambio. Los modelos y las herramientas cambian cada pocos meses. ¿Podemos fijar una versión, y quién revisa que una actualización no rompió nada?
- Manejo de datos. ¿A dónde van los prompts y las respuestas, se guardan, y se usan para entrenar?
- Plan de salida. Si el proveedor cambia precios o condiciones, ¿qué tan difícil es cambiarse?
Las herramientas de IA avanzan más rápido que cualquier otra parte del stack, y eso hace más importante, no menos, tener un responsable con nombre propio.
Un proceso simple para tu próxima decisión
- Escribe los requisitos, incluido quién va a operar la herramienta.
- Preselecciona dos o tres opciones, incluida al menos una que el equipo ya conozca, y considera si construirla con IA es una opción real.
- Califica cada opción con la matriz anterior, incluidos el encaje con la IA y la exposición de datos.
- Haz una prueba de concepto con tiempo límite sobre las mejores opciones, usando agentes de IA para avanzar rápido. Pide a un asistente que argumente en contra de tu opción favorita y luego verifica lo que dice.
- Decide, nombra un responsable y deja por escrito las razones para que el próximo equipo entienda la elección.
Cómo lo manejó el equipo
El sobrecosto de tiempo fácilmente pudo terminar en culpas. En cambio, lo tratamos como una lección compartida y escribimos la matriz juntos. Desde entonces, la gente levantó los riesgos más temprano, y eso valió más que cualquier decisión sobre una herramienta.
Lee la historia completa de la migración en De monolito a microservicios en Fincaraiz.
Recibe mis próximos casos y artículos en la Búsqueda de Google.