Problema
Muchas empresas compran herramientas de IA como si compraran software tradicional: features, precio, demo, referencias y contrato. El resultado es previsible: mas herramientas, mas excepciones, mas datos repartidos y menos control sobre como se toman decisiones.
El coste real no aparece en la factura. Aparece en integraciones fragiles, workflows duplicados, seguridad improvisada y equipos que ya no saben que herramienta es fuente de verdad.
Tesis
El procurement de IA en 2026 debe comprar menos capacidades visibles y mas control operativo. La pregunta no es “que puede hacer esta herramienta”. La pregunta es “que decision cambia, con que datos, bajo que criterios, con que owner y con que rollback”.
Comprar IA sin evaluar control operativo es financiar sprawl.
Framework
Antes de aprobar una herramienta de IA, evalua siete capas:
- Decision fit: que decision o workflow mejora.
- Data boundary: que datos toca, guarda o transforma.
- Context control: como se inyectan instrucciones, politicas y memoria.
- Evaluation: como se mide calidad, error y drift.
- Integration: donde vive en el stack real.
- Reversibility: que pasa si hay que apagarla.
- Ownership: quien responde por uso, coste y riesgo.
Mini-caso: un area de marketing compra tres herramientas de contenido con capacidades parecidas. Cada una promete velocidad. Ninguna define memoria de marca, control de claims o evaluacion de consistencia. Tres meses despues, output sube y confianza baja. El problema no era falta de generacion. Era procurement sin criterio operativo.
Senal medible: porcentaje de herramientas de IA aprobadas con owner, datos permitidos, metrica de calidad y plan de rollback antes de compra.
Postura: si una herramienta no puede apagarse sin trauma, no deberia comprarse sin rediseñar el workflow.
Respiracion: una buena demo reduce duda. Un buen procurement reduce deuda.
Checklist de compra
Antes del contrato, exige respuestas concretas:
| Capa | Pregunta |
|---|---|
| Decision fit | Que decision mejora y como sabremos que mejoro |
| Data boundary | Que datos entran, donde quedan y quien puede verlos |
| Context control | Como se actualizan reglas, tono, politicas y memoria |
| Evaluation | Que metricas detectan error, drift y retrabajo |
| Integration | Que sistemas quedan como fuente de verdad |
| Reversibility | Como se pausa, migra o apaga |
| Ownership | Quien decide renovacion, excepciones y limites |
Si el proveedor no puede responder con precision operativa, la demo todavia no esta lista para compra.
Error comun
El anti-ejemplo es dejar que cada equipo compre “su” herramienta porque resuelve un dolor local. A corto plazo parece autonomia. A medio plazo crea una arquitectura accidental donde nadie puede auditar datos, costes o decisiones.
No todo sprawl empieza con irresponsabilidad. Muchas veces empieza con equipos competentes resolviendo problemas reales sin marco comun.
Protocolo (3 pasos)
- Crea un intake unico para herramientas de IA. No para bloquear, sino para hacer visibles datos, decisiones y owners.
- Aprueba por workflow, no por categoria. Una herramienta solo entra si mejora un workflow definido y medible.
- Renueva por evidencia. Si no reduce retrabajo, mejora decision quality o baja coste operativo, se corrige o se corta.
Cuando si comprar rapido
Hay casos donde la velocidad importa: experimentos de bajo riesgo, datos no sensibles, uso individual y coste bajo. Incluso ahi conviene poner limite temporal.
Compra rapido si el rollback es trivial. Compra lento si la herramienta toca clientes, datos sensibles, decisiones economicas o memoria de marca.
Relacionado
- AI Tool Sprawl: demasiadas herramientas destruye decision
- AI Budget Allocation: invertir en casos de uso vs infraestructura
- Brand Memory Systems: consistencia como ventaja compuesta
Proximo paso
Si tu lista de herramientas de IA crece mas rapido que tu capacidad de gobernarlas, el problema ya no es procurement. Es operating model. Podemos ordenarlo en un diagnostico.