IA para Gerentes TI: build vs buy + gobernanza del wild west generativo
Decisión técnica + framework de gobernanza para Gerentes TI que tienen que llevar IA generativa a producción sin volverla un wild west. Build, buy, partner, política, presupuesto y KPIs.
Para un Gerente TI chileno en 2026, "implementar IA generativa" pasó de ser un proyecto opcional a una expectativa del C-level con presupuesto comprometido. La pregunta ya no es "si"; es "cómo": construir interno, comprar SaaS, contratar partner, qué política aplica, cuánto presupuestar, qué KPIs medir y cómo evitar el wild west donde cada área tiene su propio agente desconectado. Este cornerstone entrega el framework de decisión que aplicamos en Cognitiva con Gerentes TI chilenos: árbol Build vs Buy vs Partner, arquitectura defendible multi-modelo, política operativa de gobernanza con comité y KPIs, presupuesto realista en CLP y los siete errores caros que vemos cuando el caso parte mal estructurado. Sin teoría: lo que decimos cuando nos toca defender el caso al directorio.
La pregunta del C-level que tu Gerente TI ya no puede postergar
El gerente general ya hizo la pregunta. Probablemente más de una vez. "¿Qué estamos haciendo con IA?" El directorio quiere un plan, no una demo. Marketing y comercial ya están usando ChatGPT personal con datos corporativos. Legal está nervioso por la Ley 21.719 que entra en vigor el 1 de diciembre de 2026. El presupuesto 2026 incluyó una línea "IA" que nadie ha definido en detalle.
En esta conversación, el Gerente TI tiene tres opciones malas y una buena. Las malas: prometer demos en 30 días para tapar la urgencia, comprar un SaaS de moda para mostrar movimiento, o pedir tiempo indefinido para "evaluar". La buena: presentar un framework de decisión defendible que separe lo estratégico (build vs buy, política, KPIs) de lo táctico (proyectos concretos del próximo trimestre).
Este cornerstone es ese framework. Sirve para tres conversaciones: la del directorio (alineación estratégica), la del equipo de TI (arquitectura defendible) y la transversal con cada área (política, alcance, KPIs).
Build vs Buy vs Partner — el árbol de decisión
La primera bifurcación importante. Cada caso de uso IA en la empresa se resuelve con una de tres estrategias: build (desarrollo interno), buy (SaaS cerrado) o partner (implementador externo construye sobre tu infraestructura). No son excluyentes a nivel organización; son la decisión por proyecto.
Cuándo conviene Build
- El caso es core de la propuesta de valor (no se quiere comoditizar a través de un SaaS).
- El equipo TI tiene capacidad técnica y bandwidth real (no solo declarado).
- Los datos involucrados son sensibles y la jurisdicción importa (Ley 21.719, datos sanitarios, datos financieros regulados).
- El volumen justifica la inversión inicial (un SaaS sumaría cifras altas mensualmente a escala).
- El roadmap a 18-36 meses incluye features no disponibles en SaaS.
Cuándo conviene Buy
- El caso es periférico (no diferenciación competitiva).
- Existe un SaaS maduro con compliance enterprise (DPA serio, soporte 24/7).
- El equipo TI no tiene capacidad ni quiere desarrollarla.
- El volumen es bajo y la inversión inicial de build no se justifica.
- Time-to-value es crítico (semanas, no meses).
Cuándo conviene Partner
- El caso es estratégico pero el equipo TI no tiene profundidad en IA aún.
- Se quiere build con riesgo controlado, transferencia de conocimiento y aceleración del time-to-value.
- Hay restricciones de jurisdicción que descartan SaaS pero falta talento interno.
- El proyecto requiere combinación de habilidades (ML, integración, change management) difícil de armar internamente en plazos razonables.
La regla práctica
Para una PyME chilena con equipo TI medio: 1-2 proyectos estratégicos en modalidad Partner durante el primer año (construir capacidad interna mientras se entrega valor), 3-5 casos periféricos como Buy puro (Copilot, Notion AI, asistentes en SaaS existente), 1 caso reservado para Build cuando el equipo esté maduro a partir del año 2.
Arquitectura defendible — multi-modelo, multi-cloud, multi-stack
Cualquier arquitectura de IA que el Gerente TI defienda ante el directorio en 2026 debe responder tres preguntas: ¿qué pasa si el proveedor primario aumenta precio 3x? ¿qué pasa si la regulación nos obliga a cambiar jurisdicción? ¿qué pasa si aparece un modelo significativamente mejor en seis meses? Si la arquitectura no resuelve esas tres, es frágil.
Los tres ejes de la arquitectura defendible:
- Multi-modelo: nunca un solo proveedor LLM en producción. Configurar router con primario + fallback de calidad + fallback de costo. Vercel AI SDK abstrae bien esta capa.
- Multi-cloud: cuando sea posible, evitar acoplamiento profundo a una sola nube. Vercel + AWS para inferencia + Postgres con pgvector en tu jurisdicción es un patrón común.
- Multi-stack: separar capa conversacional, capa de orquestación (n8n), capa de datos y capa de integración (MCP). Cada capa intercambiable sin tocar las otras.
Estos tres ejes no son ideología técnica. Son la respuesta concreta a las preguntas que el directorio va a hacer cuando algo cambie. Para el detalle técnico ver el cornerstone del stack moderno.
Gobernanza — política, comité, presupuesto, KPIs
Política de uso de IA generativa
Documento de 6-10 páginas que define alcance, principios, sistemas autorizados, sistemas prohibidos, datos permitidos en prompts, responsabilidades del usuario, supervisión humana en decisiones críticas y manejo de incidentes. La plantilla Cognitiva está disponible como recurso descargable y es la base de la conversación con legal.
Tres errores comunes: política demasiado restrictiva que termina ignorada (todo el staff sigue usando ChatGPT personal), política demasiado laxa que no protege ante incidente, política sin proceso de actualización que se desactualiza en 6 meses.
Comité de Gobernanza de IA
Composición típica: Gerente TI (coordinador), Gerente Legal o Compliance, Gerente de Operaciones, Gerente RRHH (cuando hay uso interno), patrocinador C-level. Reuniones mensuales con agenda fija: revisar inventario IA, incidentes, política, capacitación y nuevos proyectos.
El comité no es un órgano que apruebe cada caso individual; es la instancia que mantiene la coherencia y resuelve dilemas que cruzan áreas.
Presupuesto realista en CLP
| Tamaño empresa | Inversión inicial primer año | Operación continua anual |
|---|---|---|
| Pequeña (15-50 personas) | CLP 15-30M | CLP 8-18M |
| Mediana (50-200 personas) | CLP 30-60M | CLP 18-40M |
| Mediana-grande (200-500 personas) | CLP 60-120M | CLP 40-80M |
Estas cifras cubren 2-3 proyectos en modalidad partner, licencias SaaS (Copilot, Claude for Work), infraestructura, capacitación y operación. Sub-presupuestar es el error más caro: el proyecto se queda en piloto eterno por falta de recursos para escalar.
KPIs que el directorio entiende
- Ahorro de horas por proceso automatizado (medido contra baseline pre-implementación).
- NPS o CSAT de los usuarios del sistema (clientes externos o personal interno según caso).
- Tasa de resolución sin escalamiento humano (para agentes conversacionales).
- Tasa de error o alucinación en producción (sample auditado mensualmente).
- Time-to-value de cada nuevo caso (tiempo entre inicio del proyecto y primer impacto medible).
- ROI a 12 y 36 meses según baseline financiero acordado.
- Cumplimiento de política IA (% del staff capacitado, % de sistemas inventariados, número de incidentes reportados).
Los 7 errores caros que vemos cuando el caso parte mal
- No designar dueño funcional del proyecto IA. Sin un nombre con accountability, el proyecto queda huérfano y nadie lo defiende cuando aparecen prioridades nuevas.
- Sub-presupuestar el mantenimiento mensual. La regla: si la inversión inicial es X, presupuestar entre X/24 y X/12 mensuales para operación continua del primer año.
- Saltarse el diagnóstico para "ahorrar tiempo". El diagnóstico de 2-4 semanas evita meses de implementación mal dirigida. Es el ROI más alto del proyecto.
- Construir un agente sin observabilidad. Sin logs, sin evals, sin métricas, no hay forma de mejorar el sistema ni de defenderlo cuando alguien cuestione su comportamiento.
- Acoplar profundamente a un proveedor LLM "porque hoy es el mejor". Los modelos cambian cada 6-12 meses. Arquitectura abstracta desde el día uno.
- Ignorar el cambio cultural. La adopción de IA es 30% técnica y 70% gestión del cambio. Sin programa de AI literacy y comunicación interna, el sistema queda subutilizado.
- Confundir piloto con producción. Un piloto exitoso no es lo mismo que un sistema productivo. La escala revela problemas (latencia, costos, gobernanza, casos edge) que en piloto no aparecen.
Plan de 90 días para Gerente TI nuevo en IA
Si recién asumes como responsable del programa IA de la empresa, este es el orden de prioridad que aplicamos:
Plan 90 días — Gerente TI nuevo en IA
Tres bloques de 30 días para establecer el programa IA desde cero como Gerente TI responsable.
- Días 1-30
Diagnóstico y baseline
Mapear lo que existe, lo que ya se usa (shadow IT incluido), lo que cuesta hoy y dónde están los quick wins.
- Inventario completo de IA en uso (incluido shadow IT)
- Baseline de costos actuales por proceso candidato
- Mapa de stakeholders por área y sus expectativas
- Identificación de 3-5 quick wins prioritarios
- Días 31-60
Gobernanza y primer quick win
Establecer las reglas (política, comité) y entregar un quick win para validar el modelo de trabajo.
- Política de uso de IA generativa aprobada y comunicada
- Comité de Gobernanza constituido con primera sesión
- Quick win implementado en modalidad partner o buy
- Primera capacitación de AI literacy al staff
- Días 61-90
Roadmap y caso al directorio
Consolidar lo aprendido y presentar al directorio el plan a 12-18 meses con presupuesto, KPIs y etapas.
- Roadmap 12-18 meses con 4-6 proyectos priorizados
- Presupuesto detallado y KPIs por proyecto
- Caso al directorio con primer quick win como evidencia
- Plan de capacitación y change management asociado
Preguntas frecuentes
Da el siguiente paso
Hablemos
Cuéntanos sobre tu negocio. Respondemos en 24 horas.
Otros canales
Escríbenos por WhatsApp o agenda una llamada de 30 minutos.