Cómo Evaluar Herramientas de IA: Guía Paso a Paso con MoSCoW y Arquitectura Empresarial

El problema no es la falta de herramientas de IA, es la falta de criterio

En los últimos veinticuatro meses, el mercado de herramientas de inteligencia artificial pasó de ser un nicho experimental a un ecosistema saturado. Copilotos, plataformas de agentes, motores RAG, orquestadores de flujos, suites de observabilidad para modelos, capas de gobernanza. Cada semana aparece una promesa nueva, cada demo es impecable y cada proveedor asegura ser el estándar del futuro.

El resultado es predecible: organizaciones que compran por entusiasmo y descubren, seis meses después, que la herramienta no se integra con su identidad corporativa, que los datos salen de su jurisdicción, que el costo por token se multiplicó por diez al escalar, o que el proveedor no ofrece trazabilidad de las decisiones del modelo. No es un problema de tecnología. Es un problema de arquitectura y de método de decisión.

Un arquitecto empresarial no evalúa herramientas por su capacidad de impresionar en una demostración. Las evalúa por su capacidad de sostener capacidades de negocio en el tiempo, bajo restricciones reales de seguridad, costo, cumplimiento y operación. Esta guía traduce esa disciplina en un procedimiento reproducible: diez pasos, cada uno con propósito, criterios, herramientas recomendadas y ejemplos concretos, articulados alrededor del método MoSCoW y anclados en marcos reconocidos como TOGAF, NIST AI RMF, ISO/IEC 42001 e ISO/IEC 25010.

Si su organización va a apostar presupuesto y reputación a la inteligencia artificial, merece hacerlo con criterio y no con intuición.

Contexto: por qué el enfoque arquitectónico cambia el resultado

El rol del arquitecto en la selección de IA

La selección de una herramienta de IA rara vez es una decisión aislada. Toca la capa de datos (¿qué información se expone?), la capa de aplicación (¿cómo se integra?), la capa tecnológica (¿dónde se ejecuta?) y la capa de negocio (¿qué capacidad habilita?). Ese cruce transversal es precisamente el territorio del arquitecto empresarial.

Su aporte no es técnico en el sentido estrecho. Es estructural: garantizar que la decisión sea trazable desde un objetivo de negocio hasta un requisito verificable, y que la herramienta elegida no genere deuda arquitectónica que otra área pagará más adelante.

Cómo TOGAF aporta estructura y gobernanza

El ADM (Architecture Development Method) de TOGAF ofrece un andamiaje natural para este ejercicio:

• Fase A (Visión): define el problema de negocio y los interesados. Aquí nace la justificación de la herramienta.
• Fase B (Arquitectura de Negocio): identifica qué capacidad se habilita y qué proceso cambia.
• Fase C (Datos y Aplicaciones): determina qué información toca el modelo y cómo se integra con el portafolio existente.
• Fase D (Tecnología): define despliegue, red, cómputo y dependencias.
• Fase E/F (Oportunidades y Planificación): compara alternativas y traza la migración.
• Fase G/H (Gobernanza y Gestión del Cambio): establece controles, métricas y revisión continua.

El Architecture Requirements Management, el proceso central que atraviesa todo el ADM, es el que sostiene los pasos 2 y 3 de esta guía: sin requisitos gestionados, no hay evaluación posible.

MoSCoW: el filtro que evita comprar por deslumbramiento

MoSCoW clasifica los requisitos en cuatro categorías: Must have (imprescindible, si falta se descarta la herramienta), Should have (importante, pero con alternativa temporal), Could have (deseable, aporta diferenciación) y Won't have this time (fuera de alcance en esta iteración).

Su virtud es brutal: convierte una conversación emocional en una comparación binaria. Una herramienta que incumple un solo Must no compite, por más brillante que sea su interfaz. Complementaremos MoSCoW con la Matriz de Pugh para ponderar los Should y Could de los finalistas.

Guía paso a paso para evaluar herramientas de IA

Paso 1. Definir objetivos de negocio y contexto

Propósito. Anclar la evaluación a un resultado medible, no a una tecnología. Sin este paso, todo lo demás es teatro.

Criterios. Objetivo expresado como métrica (tiempo, costo, calidad, riesgo); alcance de usuarios y volumen esperado; horizonte temporal; restricciones no negociables (jurisdicción de datos, presupuesto, plazo).

Herramientas recomendadas. Business Model Canvas para el encuadre, mapa de capacidades de negocio de TOGAF, OKR para expresar resultados, y Value Stream Mapping para localizar el punto exacto donde la IA interviene.

Ejemplo. En lugar de "queremos un copiloto para soporte", el objetivo se enuncia así: "reducir el tiempo medio de primera respuesta en soporte de nivel 1 de 14 a 5 minutos, sobre 8.000 tickets mensuales, sin que los datos de clientes salgan de la región, con presupuesto operativo máximo de 4.000 USD/mes". Esa frase ya elimina la mitad del mercado.

Paso 2. Identificar requisitos funcionales y no funcionales

Propósito. Traducir el objetivo en una lista verificable. Un requisito que no se puede probar no es un requisito, es un deseo.

Criterios. Funcionales: qué debe hacer (ingesta de documentos, citación de fuentes, herramientas externas, multiidioma, API). No funcionales: cómo debe comportarse, usando las características de ISO/IEC 25010 — rendimiento, seguridad, fiabilidad, mantenibilidad, portabilidad, usabilidad y compatibilidad.

Herramientas recomendadas. Catálogo de requisitos del ADM, plantillas de atributos de calidad con escenarios (estímulo, entorno, respuesta, medida) al estilo del método ATAM, y el Modelo C4 para documentar el contexto de integración.

Ejemplo. Requisito no funcional bien escrito: "Ante 200 consultas concurrentes en horario pico, el sistema devuelve la primera token en menos de 1,2 s en el percentil 95, con disponibilidad mensual del 99,9%". Compárelo con "debe ser rápido": uno se puede auditar en una prueba de concepto, el otro no.

Paso 3. Priorizar con MoSCoW

Propósito. Separar lo que decide la compra de lo que la matiza, y hacerlo antes de ver las demostraciones, para evitar que el marketing reordene sus prioridades.

Criterios. Cada requisito recibe una etiqueta consensuada con negocio, seguridad, legal y operación. Regla práctica: los Must no deberían superar el 40-50% del esfuerzo total estimado; si todo es imprescindible, nada lo es.

Herramientas recomendadas. Taller de priorización con los interesados, matriz RACI para definir quién decide, y una hoja de requisitos versionada como artefacto de arquitectura.

Ejemplo de clasificación para un asistente documental corporativo:

Requisito	Clasificación	Justificación
Residencia de datos en la región contratada	Must have	Obligación contractual y regulatoria
Citación verificable de la fuente en cada respuesta	Must have	Auditabilidad y confianza del usuario
SSO con el proveedor de identidad corporativo	Must have	Política de acceso vigente
Registro de trazas por consulta exportable a SIEM	Should have	Mitigable con integración propia a corto plazo
Ajuste fino con datos propios	Could have	Aporta valor, no bloquea la adopción
Generación de imágenes	Won't have	Fuera del alcance de esta iteración

Paso 4. Evaluar la arquitectura y el modelo de solución

Propósito. Entender cómo está construida la herramienta, no solo qué hace. La arquitectura del proveedor se convierte, tras la firma, en parte de la suya.

Criterios. Modelo de despliegue (SaaS multi-tenant, SaaS dedicado, VPC del cliente, on-premise); superficie de integración (API REST/gRPC, webhooks, SDK, conectores); acoplamiento y portabilidad (¿puede migrar de proveedor de modelo?); extensibilidad; y capacidad de operar de forma asíncrona para cargas largas.

Herramientas recomendadas. Modelo C4 para diagramar contexto y contenedores de la integración, ArchiMate para mapear el impacto en el portafolio, y una revisión de tipo ATAM para detectar puntos de sensibilidad y compromisos.

Ejemplo. Dos plataformas de agentes prometen lo mismo. Una expone el orquestador como servicio cerrado; la otra permite declarar los flujos en un formato abierto y ejecutar el modelo en un endpoint propio. La segunda cuesta un 15% más, pero elimina el bloqueo por proveedor: en un horizonte de tres años, esa diferencia se paga sola.

Paso 5. Analizar los modelos de IA utilizados

Propósito. El modelo es el corazón funcional y también el principal foco de riesgo. Una herramienta sin transparencia sobre sus modelos es una caja negra contractual.

Criterios. Modelos disponibles y posibilidad de sustituirlos; ventana de contexto y límites de tasa; política de reentrenamiento con datos del cliente (debe ser explícitamente negativa por defecto); versionado y política de deprecación; métricas de calidad en tareas propias del dominio; tratamiento de alucinaciones y estrategia de anclaje (RAG, verificación, citación).

Herramientas recomendadas. Model Cards y System Cards del proveedor, evaluaciones propias con conjuntos de prueba internos (golden dataset de 100-300 casos reales), marcos de evaluación como RAGAS o DeepEval, y pruebas de regresión ante cambios de versión.

Ejemplo. Un equipo construyó un golden dataset de 180 preguntas reales de su base documental, con respuesta esperada validada por expertos. La herramienta A alcanzó 91% de precisión factual con citación correcta; la herramienta B, 78%. La demo de B había sido más impresionante. Los datos decidieron.

Paso 6. Evaluar seguridad, privacidad y riesgos

Propósito. Determinar si la herramienta puede operar dentro de su perímetro de confianza sin ampliar la superficie de ataque más allá de lo aceptable.

Criterios. Cifrado en tránsito y en reposo; aislamiento de tenant; gestión de identidades (SSO, SCIM, RBAC granular); registro de auditoría inmutable; retención y eliminación de datos; subencargados y transferencias internacionales; y resistencia a amenazas específicas de IA — inyección de prompts, fuga de datos por el contexto, envenenamiento de la fuente de conocimiento y uso indebido de herramientas por parte del agente.

Herramientas recomendadas. NIST AI Risk Management Framework (funciones Govern, Map, Measure, Manage), OWASP Top 10 for LLM Applications, controles del Anexo A de ISO/IEC 27001 y el sistema de gestión de ISO/IEC 42001. Complemente con revisión de certificaciones (SOC 2 Tipo II, ISO 27001) y ejercicios de red teaming sobre el prompt.

Ejemplo. Durante la prueba de concepto, un ejercicio de inyección indirecta mediante un documento subido al repositorio logró que el agente revelara instrucciones del sistema y ejecutara una llamada a una herramienta no autorizada. El hallazgo no descartó a la herramienta, pero convirtió "aislamiento de herramientas por rol" en un requisito Must have que antes era Should.

Paso 7. Evaluar soporte, mantenimiento y operación

Propósito. Anticipar la vida real del sistema después del entusiasmo inicial. La operación es donde mueren los proyectos mal evaluados.

Criterios. SLA con penalizaciones reales; canales y horarios de soporte; tiempo de respuesta por severidad; madurez de la documentación; observabilidad nativa (trazas, costo por consulta, latencia, tasa de error, calidad); capacidad de exportar métricas a su propio stack; frecuencia de cambios disruptivos; y salud del proveedor (antigüedad, base de clientes, financiación).

Herramientas recomendadas. LangSmith, Langfuse o OpenTelemetry con convenciones de GenAI para observabilidad; ITIL para el modelo de servicio; y un plan de continuidad que contemple la salida del proveedor.

Ejemplo. Dos proveedores ofrecen 99,9% de disponibilidad. Al leer la letra pequeña, uno excluye las ventanas de mantenimiento y limita la compensación al 5% de la mensualidad; el otro incluye créditos escalonados y notificación con 15 días. El segundo SLA vale, en la práctica, varias veces más.

Paso 8. Evaluar costos y licenciamiento

Propósito. Calcular el costo total de propiedad y, sobre todo, cómo se comporta al escalar. El precio de entrada es la parte menos relevante.

Criterios. Modelo de cobro (por asiento, por token, por consulta, por capacidad reservada); costos ocultos (ingesta, almacenamiento vectorial, egreso de datos, entornos de prueba, soporte premium); previsibilidad ante picos; costos de integración y de formación interna; y costo de salida (migración de datos y de flujos).

Herramientas recomendadas. Modelo de TCO a 36 meses con tres escenarios (conservador, esperado, agresivo), análisis de sensibilidad sobre el volumen, y disciplina FinOps aplicada a IA con presupuestos y alertas por caso de uso.

Ejemplo. Una herramienta cobra 25 USD por asiento y otra 0,004 USD por consulta. Con 200 usuarios que hacen 12 consultas diarias, la primera cuesta 5.000 USD/mes y la segunda unos 2.100 USD/mes. Pero si el uso se duplica, la primera no varía y la segunda supera los 4.200 USD. La decisión depende de la curva de adopción esperada, no de la tarifa nominal.

Paso 9. Evaluar el cumplimiento normativo

Propósito. Verificar que el uso previsto es defendible ante un regulador, un auditor o un cliente corporativo.

Criterios. Clasificación de riesgo del caso de uso; base legal para el tratamiento de datos personales; derechos de los titulares; propiedad intelectual de las entradas y salidas; obligaciones de transparencia (informar al usuario de que interactúa con IA); documentación técnica y trazabilidad de decisiones; y supervisión humana en casos de impacto significativo.

Herramientas recomendadas. ISO/IEC 42001 como sistema de gestión de IA, el enfoque por niveles de riesgo del Reglamento Europeo de IA como referencia metodológica aplicable en cualquier jurisdicción, evaluaciones de impacto (DPIA), y matrices de cumplimiento normativo por región.

Ejemplo. Un sistema de apoyo a la preselección de candidatos se clasifica como de alto impacto en prácticamente cualquier marco. Eso obliga a documentar el conjunto de criterios, registrar cada recomendación, permitir la revisión humana y realizar pruebas de sesgo periódicas. Si la herramienta no expone la trazabilidad necesaria, queda descartada aunque su desempeño sea superior.

Paso 10. Construir la matriz comparativa y decidir

Propósito. Convertir toda la evidencia acumulada en una decisión defendible, con criterios explícitos y ponderaciones acordadas antes de puntuar.

Criterios. Primero, filtro binario de Must have: quien incumple uno, sale. Después, puntuación ponderada de los finalistas sobre los Should y Could, con escala de 1 a 5 y pesos que sumen 100%.

Herramientas recomendadas. Matriz de Pugh o de decisión ponderada, prueba de concepto acotada (dos a cuatro semanas) con criterios de éxito definidos de antemano, y registro de la decisión como ADR (Architecture Decision Record).

Ejemplo de matriz ponderada:

Criterio	Peso	Herramienta A	Herramienta B	Herramienta C
Calidad sobre el conjunto de prueba	25%	5	4	3
Seguridad y privacidad	20%	4	5	3
Integración y portabilidad	15%	3	5	4
Costo total a 36 meses	15%	3	3	5
Operación y observabilidad	15%	4	4	3
Cumplimiento normativo	10%	4	5	3
Total ponderado	100%	3,95	4,30	3,50

La herramienta B gana no por ser la mejor en todo, sino por su equilibrio en los criterios de mayor peso. Y el resultado es reproducible: cualquiera puede revisar la puntuación y discutir los pesos, que es exactamente el tipo de conversación que debe tener un comité de arquitectura.

Recomendaciones prácticas y buenas prácticas

Defina los criterios antes de ver las demostraciones. Es la regla más simple y la más incumplida. Una demo bien ejecutada reordena prioridades sin que el equipo lo note.

Pruebe con sus datos, no con los del proveedor. Un golden dataset de casos reales, aunque sea de cien ejemplos, aporta más información que tres meses de reuniones comerciales.

Involucre a seguridad y legal desde el paso 2, no en el paso 9. Un veto tardío destruye semanas de trabajo y credibilidad.

Evalúe la trayectoria de deprecación. Los modelos se retiran. Pregunte cuánto aviso previo da el proveedor y qué ocurre con los flujos que dependen de una versión concreta.

Diseñe siempre una ruta de salida. Si no puede describir en un párrafo cómo migraría a otro proveedor en noventa días, el acoplamiento ya es demasiado alto.

Errores frecuentes que conviene evitar: confundir capacidad del modelo con capacidad del producto; convertir todos los requisitos en Must have; extrapolar el costo desde un piloto de bajo volumen; ignorar el costo de la formación interna; y decidir sin registrar la decisión, lo que condena a repetir la discusión cada seis meses.

Criterios de calidad del propio proceso: la evaluación debe ser reproducible por otra persona, trazable hasta un objetivo de negocio, documentada en un ADR y revisable en un plazo definido — porque en inteligencia artificial, una decisión correcta hoy puede dejar de serlo en doce meses.

Conclusión: la ventaja competitiva está en el método

La adopción de inteligencia artificial dejó de ser una cuestión de acceso. Prácticamente cualquier organización puede contratar hoy un modelo de frontera con una tarjeta de crédito. Lo que separa a quienes obtienen valor de quienes acumulan suscripciones no es la herramienta: es el rigor con que se elige, se integra y se gobierna.

Un proceso de evaluación estructurado no es burocracia. Es la diferencia entre una capacidad que escala y un piloto que se apaga; entre una decisión que se puede defender ante un auditor y una que se justifica con una anécdota. TOGAF aporta el andamiaje, MoSCoW impone la disciplina, NIST AI RMF e ISO/IEC 42001 sostienen el riesgo y la gobernanza, y la matriz ponderada convierte el juicio experto en evidencia comunicable.

El futuro de la IA en la empresa no pertenecerá a quienes adopten más rápido, sino a quienes adopten con criterio y sepan cambiar de rumbo sin desmontar su arquitectura. Construya su catálogo de requisitos, defina sus Must have, arme su conjunto de prueba y exija evidencia. La próxima vez que un proveedor le muestre una demostración impecable, usted tendrá algo mucho más valioso que entusiasmo: un método.