La mejor propuesta de arquitectura de IA no es la que incluye más cajas, modelos o productos. Explica por qué cada decisión sirve al resultado, qué supuestos aún deben probarse, cómo falla y se recupera el sistema, cuánto cuesta operarlo y cómo sustituir componentes. Antes de contratar, compare registros de decisión y evidencias ejecutables, no la estética del diagrama.
La arquitectura debe ser proporcional a la decisión. Un asistente interno con revisión humana puede requerir una integración simple y un servicio gestionado. Un agente que ejecuta acciones relevantes, procesa datos sensibles o opera a gran volumen necesita controles, evaluación, observabilidad y rutas de desactivación más fuertes. Complejidad sin valor o reducción de riesgo equivalente es un pasivo.
AI Architecture Decision Proof-8: matriz de 32 puntos
Puntúe cada dimensión de cero a cuatro: cero es ausente; uno es afirmación; dos es diseño parcial; tres es decisión justificada con evidencia y owner; cuatro es decisión reproducida en condiciones representativas, con alternativa y gatillo de revisión. Como corte ilustrativo, exija 24 de 32, ningún cero y mínimo tres en datos, seguridad, evaluación y operación.
- Resultado y fronteras — usuario, tarea, autonomía, exclusiones, baseline, error tolerable y alternativa sin IA son explícitos.
- Datos y contexto — fuentes, derechos, calidad, recuperación, memoria, actualización, retención y procedencia sostienen el uso real.
- Modelos y herramientas — servicio gestionado, RAG, herramientas, fine-tuning o código propio se comparan con evidencia.
- Integraciones e interfaces — sistemas de registro, APIs, eventos, identidad, límites, idempotencia y fallas están definidos.
- Seguridad y cadena — ambientes, secretos, accesos, componentes, subcontratistas, versiones, vulnerabilidades e incidentes son controlables.
- Evaluación y supervisión — conjuntos, métricas, casos adversos, revisión humana, aprobación, regresión y parada son ejecutables.
- Confiabilidad y operación — observabilidad, SLOs, fallback, rollback, cambio de modelo, continuidad, soporte y retiro tienen owners.
- Economía y salida — costo por resultado, capacidad, concentración, portabilidad, formatos, documentación y transición son demostrables.
Aplique cinco filtros eliminatorios antes del puntaje
- El diseño depende de datos, acceso o integración que nadie verificó.
- Una acción irreversible o de alto impacto carece de autorización, límites e intervención humana proporcionales.
- No existe un conjunto de evaluación representativo ni criterio de aceptación reproducible.
- Un componente crítico de tercero no tiene owner, monitoreo, contingencia o derecho de sustitución.
- El proveedor no puede exportar código, configuración, datos, prompts, evaluaciones, logs y documentación para la transición.
Reprobar un filtro no exige abandonar el caso. Cambia la compra hacia discovery técnico limitado, spike de integración, evaluación independiente o piloto controlado. No adjudique una implementación completa para financiar el descubrimiento tardío de un supuesto arquitectónico crítico.
Compare cuatro patrones sin perseguir modas
- Servicio gestionado y configuración — aceleran entrega y reducen operación propia; aclare límites, datos, precio, disponibilidad y salida.
- RAG e integración empresarial — pueden conectar respuestas con contenido autorizado; dependen de ingestión, recuperación, permisos, evaluación y actualización.
- Agentes y orquestación — permiten ejecutar flujos y herramientas; amplían superficie de acción, excepciones, identidad, observabilidad y controles.
- Componentes propios o fine-tuning — pueden atender dominio, desempeño o escala específicos; exigen datos, evaluación, MLOps, capacidad y costo sostenibles.
Exija siete artefactos comparables
- Diagrama de contexto con usuarios, sistemas, datos, terceros y fronteras de confianza.
- Registros de decisiones críticas, alternativas rechazadas, evidencia, owner y gatillo de revisión.
- Modelo de amenazas y cadena de componentes con versiones, accesos y contingencias.
- Plan de evaluación ligado a requisitos, riesgo, condiciones reales y criterios de aceptación.
- Modelo operativo con telemetría, SLOs, incidentes, cambios, fallback, rollback y retiro.
- Modelo de costo y capacidad por escenario, con volumen, latencia, revisión humana e incertidumbre.
- Paquete de portabilidad y transición con formatos, repositorios, documentación, dependencias y prueba de sustitución.
Realice una defensa adversarial de 90 minutos
Entregue el mismo brief a los finalistas. Pida defender tres decisiones y una alternativa rechazada. Luego retire el modelo principal, degrade la recuperación, cambie el esquema de una API, aumente el volumen y exija borrar datos. Solicite diagnóstico, aislamiento, fallback, impacto en costo y plazo y registro de decisión. Evalúe claridad de supuestos, sustitución de componentes y comportamiento ante incertidumbre, no la velocidad para dibujar más cajas.
Señales de alerta comerciales y técnicas
- Una tecnología aparece antes del problema y los requisitos.
- Toda decisión se llama estándar o best practice sin comparación.
- Integración, evaluación, observabilidad, revisión humana y soporte quedan fuera del precio.
- El diagrama omite identidad, ambientes, datos sensibles, terceros u operación.
- La solución depende de un modelo, pero no hay prueba de sustitución.
- La promesa de escala carece de modelo de carga, cuellos y costo por resultado.
- El cliente recibe la documentación solo al final.
Contexto de América Latina
En América Latina, revise la arquitectura país por país: finalidad, controlador, operadores y suboperadores, transferencias internacionales, retención, derechos de los titulares, requisitos sectoriales, contrato, moneda e impuestos pueden variar. No trate la región como una sola jurisdicción ni el procesamiento local como garantía de seguridad. Incluya nube, modelos, conectividad, soporte, revisión humana y gestión interna en el costo total. Legal, privacidad, seguridad, arquitectura y compras deben trabajar sobre la misma versión controlada.
Lleve la arquitectura al RFP y al contrato
Entregue a todos el mismo escenario, restricciones y volúmenes. Exija separar hechos de supuestos, opciones arquitectónicas, dependencias del cliente, criterios de aceptación y precios por escenario. Vincule hitos con artefactos reproducibles, reserve revisión cuando cambien contexto o modelos y defina propiedad, licencias, repositorios, exportación, asistencia de transición y límites a la subcontratación.
Conecte arquitectura con las demás decisiones
Use https://makinai.co/insights/es/comprar-configurar-o-desarrollar-solucion-ia para definir la frontera tecnológica, https://makinai.co/insights/es/evaluar-preparacion-datos-antes-contratar-empresa-ia para probar entradas, https://makinai.co/insights/es/due-diligence-seguridad-contratar-empresa-ia para profundizar controles y https://makinai.co/insights/es/como-evitar-lock-in-contratar-proveedor-ia para validar portabilidad y salida.
Cuándo involucrar a MAKINAI
MAKINAI puede convertir propuestas arquitectónicas en decisiones comparables, conducir la defensa adversarial y transformar supuestos en discovery, gates, criterios de aceptación y plan de transición. Conozca https://makinai.co/services/es/consultoria-estrategia-ia-transformacion.