Construir en casa o con un partner

El gerente de TI de una empresa mediana tiene tres personas en su equipo. Esta semana resolvieron una caída del correo, renovaron licencias, dieron acceso a cuatro personas nuevas, atendieron una alerta de seguridad y respondieron cuarenta tickets. Desde el directorio le piden un plan para poner agentes de IA en la operación antes de fin de año. Él sabe hacerlo. Lo que no tiene es tiempo, ni un equipo que pueda dedicarse a eso sin descuidar lo demás.

Es la última composición de esta temporada. Las piezas que recorrimos —interfaces, definiciones, evaluaciones, seguridad y trazabilidad según el caso— necesitan responsables de construcción y mantenimiento. La pregunta es quién tiene capacidad para asumirlas.

El verdadero cuello de botella

La competencia técnica es solo una parte de la decisión. Aunque el equipo de TI conozca bien los sistemas, puede tener su tiempo comprometido en sostenerlos. Construir y mantener las piezas necesarias para cada agente exige capacidad asignada, además de conocimientos que hay que actualizar: modelos, protocolos, evaluación y seguridad.

Pedirle eso a un equipo que apaga incendios todo el día arriesga retrasar el proyecto o degradar el soporte que ya presta.

Cuándo tiene sentido construir en casa

Construir internamente puede ser la mejor opción cuando la empresa puede dedicar un equipo estable a esto, cuando la tecnología es parte de su propuesta de valor, o cuando la escala justifica tener especialistas propios en datos, IA y seguridad. En esos casos, la curva de aprendizaje es una inversión que se queda en la empresa.

Cuándo tiene sentido un partner

Un partner puede tener sentido cuando TI no puede liberar gente sin afectar la operación o cuando faltan capacidades especializadas. También puede ayudar a coordinar procesos que cruzan áreas. Eso no garantiza rapidez: hay que evaluar experiencia, alcance, tiempo de integración y dependencia futura frente a construir con el equipo interno.

Un buen partner no reemplaza a tu equipo de TI. Lo saca del rol de bombero y lo pone a decidir.

Cómo distinguir un buen partner de uno malo

• Construye sobre tu lógica, no sobre su plantilla: los módulos reflejan cómo trabaja tu empresa.
• Trabaja con tu equipo, no en paralelo a él: TI participa en las decisiones y conoce cómo funciona todo.
• Deja capacidad instalada: documentación, acceso completo y conocimiento transferido, no una caja negra.
• El contrato define acceso y exportación de datos, reglas y registros en formatos documentados, con plazos y condiciones de salida verificables.
• Mide resultados en tu operación, con los mismos indicadores que usa el negocio, no con métricas propias.

Lo que nunca se delega

Se puede delegar la construcción y parte de la operación técnica. La empresa debe conservar la capacidad de decidir sobre sus datos, sus reglas y sus prioridades, con acceso y condiciones de salida por escrito. La temporada anterior terminó con una idea: la ventaja no viene en una licencia. Esta cierra con una consecuencia práctica: tampoco conviene dejarla encerrada en la plataforma de un proveedor.

Un modelo posible es mixto. El partner ayuda a construir y mantener componentes compartidos; el equipo interno conserva las reglas, las prioridades y la relación con el negocio. El contrato debe definir documentación, acceso, transferencia de conocimiento y responsabilidades de mantenimiento. Con el tiempo, la empresa puede asumir más trabajo si tiene capacidad para hacerlo.

Gracias por acompañarnos en esta segunda temporada.

Las escenas de estos episodios son composiciones de situaciones frecuentes, no casos de clientes. Las cifras que aparecen en ellas son ilustrativas.