Cómo armar un equipo de IA interno sin copiar el organigrama de una startup

Por qué la mayoría arma mal su primer equipo de IA

La mayoría de empresas medianas comete el mismo error cuando decide meterle gente a la IA: contratan antes de saber para qué. Aparece un puesto de “Head of AI” o “Gerente de Transformación Digital” sin que exista todavía un caso de uso probado, un presupuesto real o un dato limpio con el que trabajar. Ese cargo termina llenando presentaciones, no construyendo sistemas.

El otro error, más silencioso, es el contrario: delegarle la IA al área de sistemas existente sin darle ni el tiempo ni la autoridad para tomar decisiones de negocio. El resultado es un integrador que conecta APIs pero no puede explicarle a la gerencia comercial por qué ese flujo automatizado le ahorra dinero. Sistemas sabe programar, no necesariamente sabe diagnosticar un proceso ni priorizar entre casos de uso.

Esta guía no es sobre construir un área de IA de diez personas. Es sobre el equipo mínimo real: qué roles existen de verdad (no los que suenan bien en LinkedIn), cuál conviene tercerizar al inicio, cuándo contratar a la primera persona interna y qué señal concreta indica que ya toca sumar un segundo perfil.

Qué es, en concreto, armar un equipo de IA interno

Esto no es contratar ingenieros de machine learning ni fichar a alguien con un máster en IA. Es cubrir tres funciones que existen en cualquier proyecto de IA que funciona, sin importar el tamaño de la empresa, y decidir con qué combinación de gente propia, contratada y tercerizada se cubre cada una. El error de fondo es tratar esto como un problema de organigrama cuando en realidad es un problema de secuencia: qué función cubres primero, con quién, y cuándo agregas la siguiente.

Los tres roles que existen de verdad (nada de organigrama de startup)

1. Quién diagnostica y traduce negocio

Esta persona entiende los procesos de la empresa, cuantifica el dolor en horas o en plata, decide qué caso de uso va primero y le explica el resultado a finanzas y a operaciones en su idioma, no en el de la tecnología. Es el rol que casi nadie tiene adentro al inicio, y no pasa nada: se puede tercerizar con un consultor senior mientras se valida el primer caso de uso. Lo que no puede pasar es que este rol quede vacío, porque sin él el proyecto se convierte en tecnología sin negocio.

2. Quién implementa y mantiene

Esta persona construye las integraciones, ajusta los prompts o los flujos de agentes, monitorea que todo siga funcionando y arregla lo que se rompe. Es, casi siempre, la primera contratación interna real, porque el mantenimiento diario necesita continuidad y conocimiento institucional que un tercero de paso no acumula igual. Contratar aquí antes de tener algo que mantener es gastar sueldo en gente esperando trabajo.

3. Quién es dueño del dato

Alguien tiene que responder por la calidad, el acceso y la estructura de la información que alimenta cualquier sistema de IA. Casi nunca es una contratación nueva: suele ser un rol que ya existe (el gerente de operaciones, el líder de finanzas) al que se le asigna esta responsabilidad de forma explícita y con autoridad real, no solo de nombre.

El paso a paso para armar el equipo, en orden

• Antes de contratar a nadie, corre un diagnóstico de madurez y elige el primer caso de uso, apoyado en un tercero si todavía no tienes a nadie interno con criterio para hacerlo.
• Cubre el rol de diagnóstico con un consultor o freelance senior por proyecto, no por planilla, mientras validas entre dos y tres casos de uso reales.
• Contrata a la primera persona interna recién cuando el piloto ya funciona y necesitas que alguien lo mantenga todos los días, no antes de tener algo que mantener.
• Define el perfil de esa primera contratación como alguien con criterio técnico y de negocio a la vez, no un especialista puro en un framework o una herramienta de moda.
• Asigna formalmente el rol de dueño del dato a alguien que ya trabaja en la empresa; no contrates para esto en la fase inicial.
• Documenta desde el primer día quién decide qué, para no depender de la memoria de una sola persona ni de que esa persona nunca se vaya.

Contratar, formar a alguien de adentro o tercerizar: cómo decidir

No hay una respuesta única entre contratar, formar a alguien de adentro o tercerizar. Depende de qué tan validado está el caso de uso, de si ya existe alguien adentro con la mitad del perfil, y de cuánto dura la necesidad real.

Terceriza cuando:

• El caso de uso todavía no está probado y necesitas a alguien que diagnostique sin comprometerte a una contratación de largo plazo.
• La necesidad es puntual: migrar automatizaciones sueltas a un sistema, auditar los riesgos de un proveedor, escribir el primer PRD del proyecto.
• Todavía no hay volumen suficiente de trabajo de IA como para ocupar a una persona a tiempo completo.

Forma a alguien de adentro cuando:

• Ya tienes en sistemas u operaciones a alguien con criterio de negocio y ganas reales de aprender, no solo curiosidad pasajera.
• El conocimiento de los procesos internos pesa más que el conocimiento técnico puro: es más rápido enseñarle IA a quien entiende el negocio que enseñarle el negocio a un técnico de afuera.
• Puedes darle tiempo protegido y capacitación real sin que su rol actual colapse mientras aprende.

Contrata de afuera cuando:

• El piloto ya demostró resultado y necesitas mantenimiento diario que nadie interno puede absorber sin descuidar su trabajo actual.
• Necesitas una segunda mirada técnica que nadie adentro tiene, y el volumen ya justifica planilla, no un proyecto puntual.
• La rotación de consultores externos ya te costó continuidad: perdiste contexto más de una vez al cambiar de proveedor.

Errores comunes al armar un equipo de IA interno

• Contratar un “Head of AI” senior y caro antes de tener un solo caso de uso funcionando en producción: se paga sueldo de dirección por trabajo de diagnóstico que un consultor cobra por proyecto.
• Pedirle a sistemas que “también vea IA” sin quitarle carga actual ni darle autoridad de decisión sobre procesos de negocio.
• Copiar el organigrama de una empresa de tecnología de quinientas personas (Head of AI, ingenieros de machine learning, científicos de datos, ingenieros de prompts) para una empresa de ochenta.
• No asignar el rol de dueño del dato a nadie: el proyecto se estanca porque nadie responde cuando la información está mal o incompleta.
• Contratar dos perfiles técnicos al mismo tiempo antes de validar el primero: duplicar el gasto sin haber probado si el primer piloto realmente funciona.

Cómo se ve esto en la práctica

Una empresa de manufactura mediana, alrededor de doscientos empleados, sin nadie dedicado a IA, arrancó con un consultor externo por dos meses para hacer el diagnóstico y elegir el primer caso de uso: automatizar la conciliación de órdenes de compra contra facturas de proveedores. El consultor no quedó en planilla, cobró por el proyecto y entregó el flujo documentado.

Cuando el piloto empezó a funcionar y a ahorrar horas reales cada semana, contrataron a su primera persona interna: no un ingeniero de IA puro, sino alguien con experiencia en sistemas que además entendía el proceso de compras. Esa persona quedó a cargo de mantener el flujo, arreglarlo cuando fallaba y ampliarlo a un segundo proceso.

El dato quedó bajo responsabilidad formal del gerente de operaciones, que ya trabajaba ahí: se le agregó explícitamente esa función a su rol, no se contrató a nadie nuevo para eso. Recién a los ocho meses, cuando la cola de procesos por automatizar superó lo que una persona podía sostener sola, sumaron un segundo perfil técnico.

Mi criterio

Cómo medir si el equipo quedó bien armado

• La persona interna puede explicar, en una frase, qué proceso de negocio mejora cada sistema que mantiene; si no puede, es un técnico sin criterio de negocio.
• El dueño del dato responde en menos de 48 horas cuando hay un problema de calidad de información; si nadie responde, el rol no está asignado de verdad, solo en el papel.
• El costo del equipo, interno más tercerizado, es menor que el valor medible que generan los casos de uso ya en producción, no una apuesta a futuro.
• Cuando la persona clave se toma vacaciones o se enferma, los sistemas siguen corriendo sin intervención diaria: señal de que no dependes de una sola cabeza sin documentación.
• Existe una señal cuantificable, no una sensación, de que se necesita un segundo perfil: cola de solicitudes, horas de mantenimiento que ya no caben en una jornada, o número de sistemas en producción.