Tu directorio quiere una estrategia de IA. Tus competidores tienen notas de prensa. Tú tienes un presupuesto, una hoja de ruta ya llena y una pila creciente de presentaciones de proveedores que dicen las mismas tres cosas. Este es el momento en que se tuerce casi toda la adopción de IA: no en la tecnología, sino en la decisión que tomas antes de escribir la primera línea.
Va la verdad incómoda: una estrategia de IA sin un sistema en producción es teatro. Una diapositiva que dice «somos AI-first» no vale nada hasta que hay algo en producción, recibiendo entradas reales y siendo medido. Todo lo que sigue trata de cómo llegar a ese sistema sin prenderle fuego al dinero.
Comprar, construir y asociarse son tres preguntas, no una
Casi todo el mundo lo reduce a «¿deberíamos construirlo nosotros?». Es el marco equivocado. Plantéalo como tres decisiones separadas.
Compra cuando la capacidad ya es un commodity y no te diferencia. Transcripción, extracción genérica de documentos, chat de soporte estándar: paga por eso. Construirlo es ego, no estrategia.
Construye cuando el workflow es tu ventaja competitiva y vive sobre tus datos propios. Si solo funciona gracias a un contexto que nadie más tiene, ser dueño de él es justamente el punto.
Asóciate cuando necesitas construir algo diferenciado pero todavía no tienes el músculo interno de eval, tracing y MLOps para lanzarlo con seguridad. Aquí es donde de verdad está casi toda la empresa mediana. El error es fingir que estás en la columna de «construir» cuando tu equipo nunca ha operado un arnés de evaluación en producción.
Sé honesto sobre en qué columna cae cada proyecto. Una sola «iniciativa de IA» suele contener las tres.
El lock-in es un costo que pagas después, en silencio
Cuando compras o te asocias, pregunta exactamente a qué quedas atado. Hay tres capas, y a los proveedores les encanta difuminarlas.
El lock-in de modelo es el superficial: cambiar de proveedor debería ser un cambio de configuración, y si alguien lo convierte en una reescritura, eso es una señal de alarma. El lock-in de datos es más hondo: ¿de quién son los prompts, los traces, los sets de fine-tuning y los datos de eval etiquetados que vas acumulando? Esos datos son el activo real. Si viven en un formato que no puedes exportar, estás alquilando tu propio conocimiento institucional. Y el lock-in de workflow es el asesino silencioso: el sistema del proveedor queda tan incrustado en tu operación que irte significa rediseñar un proceso de negocio.
No hace falta evitar todo lock-in. Hace falta saber cuál estás aceptando a propósito y ponerle precio.
Tu preparación de datos y de seguridad lo decide todo
El modelo es la parte menos interesante de tu adopción de IA. Lo difícil es que los sistemas de IA leen y escriben a lo ancho de tus datos, y tus controles de acceso no se diseñaron para un componente al que se le puede convencer de hacer cosas.
Antes de adoptar, responde con claridad: ¿tus datos son realmente recuperables, o están atrapados en PDFs y conocimiento tribal? ¿Tus límites de permisos sobreviven a un agente que actúa en nombre de un usuario, o hereda modo dios? ¿Cuál es tu exposición a la inyección de prompts cuando el sistema lee contenido no confiable? Si no puedes contestar esto, no estás listo para adoptar: estás listo para hacer antes una auditoría de datos y seguridad. Eso no es un retraso. Eso es el trabajo.
Las preguntas de eval y de costo total que cualquier proveedor debe sobrevivir
Dos preguntas separan un sistema real de una demo.
Primera: enséñame tu eval. No un benchmark: tu eval, sobre mi tipo de datos, con los casos de fallo etiquetados. Si un proveedor no sabe decirte cómo mide la corrección en tareas como las tuyas, te está vendiendo una sensación. Una demo que funciona no es evidencia: es una muestra de tamaño uno que alguien eligió.
Segunda: ¿cuál es el costo total de propiedad?, no el precio por token. El costo por token es la etiqueta del escaparate. La factura real incluye la latencia a tu volumen, el ciclo de revisión humana para todo lo de alto riesgo, los retries y los planes de respaldo, el monitoreo y el tiempo de ingeniería para mantener los evals al día mientras los modelos cambian bajo tus pies. Pídele a un proveedor que ponga precio a un mes realista a tu escala. Fíjate en lo rápido que ese número tan seguro se vuelve borroso.
Habilidades del equipo y gobernanza, sin caer en la parálisis
Necesitas gente capaz de leer un trace y decirte por qué un agente hizo lo que hizo, no solo gente que escriba prompts. Si nadie en tu equipo puede depurar una tool call fallida, no puedes operar el sistema que estás comprando: solo puedes esperar que siga funcionando.
Sobre gobernanza: la Ley de IA de la UE y sus primas son reales, y deberías saber en qué categoría de riesgo cae tu caso de uso. Pero no dejes que el cumplimiento se convierta en la excusa para no lanzar nunca. La gobernanza de un sistema autónomo de cara al cliente y la de un asistente interno de redacción son problemas distintos. Dimensiónala bien. Una política ligera y defendible que te deja lanzar le gana a un marco perfecto que deja todo en comité.
Protégete del purgatorio de los pilotos
El fallo más común en la adopción de IA no es un sistema que se rompe. Es un piloto que nunca muere y nunca sale: perpetuamente «prometedor», perpetuamente a tres semanas de producción. El purgatorio aparece cuando no hay un listón acordado de antemano sobre qué significa «lo bastante bueno para lanzar».
Arréglalo antes de empezar. Define la métrica, el umbral y la fecha de decisión desde el primer día. Si el piloto llega al listón, lanzas. Si no llega, lo matas y te quedas con la lección. Las dos cosas son victorias. Un piloto sin criterios de muerte no es un piloto: es una suscripción a la esperanza.
Nada de esto exige que te vuelvas investigador de IA. Exige que reclames el mismo rigor que ya aplicas a cualquier otro sistema que pones en producción. Una Evaluación de Preparación para IA es exactamente ese rigor, aplicado temprano: un plan defendible anclado en tus datos, tus riesgos y tu equipo, en lugar de en la presentación de un proveedor. Consigue primero el plan. Después lanza el sistema.