Cómo gestionan las operaciones de IA en una empresa pequeña
Una startup que está empezando a escalar sus herramientas de IA debate si la gestión debe quedar en el equipo de plataforma/devops o distribuirse entre los demás grupos.
Una compañía con pocos empleados está comenzando a adoptar herramientas de inteligencia artificial y ya siente la presión para ampliar su stack. Hasta ahora usan algunos modelos internos, pero la demanda de más soluciones está creando un escenario de "free‑for‑all" donde varios equipos compiten por liderar la iniciativa.
El responsable del equipo de plataforma y devops asume que, por ser el grupo más técnico, debería encargarse de todo lo relacionado con la operación de IA: evaluación de modelos, habilitación, definición de guardrails, seguridad y observabilidad. La visión que tiene es que los arquitectos elijan la solución, consulten al equipo de plataforma y luego este implemente y mantenga la infraestructura necesaria.
Sin embargo, la pregunta que plantea a la comunidad es si esa estructura es la más eficaz. Algunas organizaciones crean una función dedicada a IA, con roles especializados en modelado, MLOps y gobernanza, mientras que otras integran esas responsabilidades en equipos de datos, seguridad o incluso en los squads de producto. La diferencia clave suele estar en el nivel de madurez de la IA dentro de la empresa y en la claridad de los procesos de entrega.
En entornos pequeños, centralizar la operativa de IA en devops puede simplificar la gestión de recursos y evitar la duplicación de esfuerzos. El equipo ya maneja CI/CD, orquestación de contenedores y monitorización, por lo que añadir pipelines de entrenamiento y despliegue de modelos no es un salto enorme. Además, el control de acceso y la auditoría de datos pueden quedar bajo la misma política que el resto de la infraestructura.
Por otro lado, delegar esas tareas a otros equipos puede acelerar la adopción en áreas específicas. Un equipo de producto que controla directamente su modelo puede iterar más rápido, siempre que cuente con las guías de seguridad y observabilidad adecuadas. El riesgo es la proliferación de entornos sin control, lo que dificulta la aplicación de políticas de guardrails y la detección de vulnerabilidades.
En la práctica, muchas organizaciones optan por un modelo híbrido: un núcleo de MLOps dentro de devops que provee plataformas (por ejemplo, Kubeflow, MLflow o SageMaker) y define estándares, mientras que los equipos de dominio consumen esos servicios bajo sus propias responsabilidades. Este enfoque mantiene la consistencia operativa sin bloquear la velocidad de desarrollo.
Queda por ver cuál será la mejor configuración para cada caso. La comunidad sigue compartiendo experiencias, y la respuesta dependerá del tamaño del equipo, la complejidad de los modelos y la cultura de colaboración interna.
