En el ámbito de la IA, el problema no es técnico, sino que tiene que ver con el criterio
Para 2026, casi cualquier equipo técnico sabrá cómo utilizar modelos de IA. La documentación es pública, las API son accesibles y la barrera de entrada técnica se ha reducido drásticamente. Lo que no se ha reducido es la barrera de la toma de decisiones: saber dónde aplicar la IA, dónde no, con qué pila tecnológica, en función de qué métricas y con qué justificación normativa. Esa barrera no se supera con personal junior, cursos o marcos de trabajo. Se supera con el criterio de los profesionales con experiencia, acumulado a lo largo de años de proyectos reales.
En una empresa de servicios públicos alemana, esta diferencia resulta especialmente evidente. La IA se aplica a sistemas críticos (SAP IS-U, FI-CA, Powercloud, comunicación de mercado) que operan bajo las normas del BSI, el RGPD y KRITIS, y están sometidos a un escrutinio continuo por parte de la Bundesnetzagentur. Una decisión mal calibrada no genera un error: genera un riesgo normativo, costosas modificaciones posteriores o la pérdida de confianza interna en la propia IA.
«En el ámbito de la inteligencia artificial, la diferencia no radica en utilizar el modelo adecuado, sino en decidir si realmente conviene utilizarlo».
¿Qué se pierde cuando un proyecto de IA se lleva a cabo con equipos de principiantes o rotativos?
Cuando un proyecto de IA en una empresa de servicios públicos se lleva a cabo con personal sin experiencia y sin una tutoría real por parte de profesionales con más experiencia, o con equipos que rotan cada seis meses, se repiten constantemente tres patrones.
01 · Sobredimensionamiento
Se opta por el modelo más grande, más nuevo o más de moda, incluso cuando una solución más sencilla sería adecuada. El proyecto piloto resulta caro de justificar ante los departamentos de finanzas y de cumplimiento normativo.
02 · Calibración deficiente del osciloscopio
Sin experiencia previa, el equipo dice que sí a todo. Un miembro con más experiencia sabe reconocer cuándo hay que ampliar la fase de exploración y cuándo hay que decir «esto no es un problema de IA».
03 · Pérdida de continuidad
Las decisiones descartadas, las hipótesis validadas y los sesgos de datos identificados quedan fuera de la documentación. Cuando los equipos rotan, el siguiente ciclo tiene que volver a invertir el doble en el mismo aprendizaje.
¿Qué aporta un consultor sénior que un becario o un consultor junior no puede aportar?
Un consultor sénior especializado en IA aporta tres competencias que ni un modelo ni un profesional con menos experiencia pueden igualar.
✓ Sentencia
Saber en qué ámbitos tiene cabida la IA (clasificación, previsión, detección de anomalías, resumen de documentos) y en cuáles solo supone un riesgo (decisiones vinculantes, procesos determinísticos, cálculos sujetos a normativa). Esa información evita meses de pruebas piloto inútiles.
✓ Contexto del sector
Cómo funciona MaKo, cómo evoluciona la normativa de la BNetzA, cómo se integra SAP IS-U con FI-CA y el portal, y qué datos pueden salir del entorno en el marco de la normativa KRITIS o del RGPD. Nada de esto se enseña en ningún curso de máster en Derecho.
✓ Decir «no»
Un responsable de alto nivel rechaza un caso de uso mal definido antes de que se convierta en un proyecto fallido. En el ámbito de la IA, decir «no» a tiempo protege el retorno de la inversión del cliente mucho más que decir «sí» con entusiasmo.
Cuatro momentos decisivos en los que la experiencia marca la diferencia
Hay cuatro momentos clave en un proyecto de IA en una empresa de servicios públicos alemana que determinan el resultado final en función de la experiencia del equipo.
01 · Definición del alcance
Centrar el proyecto en dos o tres casos de uso con un valor demostrable a corto plazo, en lugar de en un catálogo de proyectos piloto inconexos.
02 · Selección de la tecnología
Aplicación de criterios realmente independientes de la IA: código abierto para la soberanía, hiperescaladores para la escala y modelos pequeños y optimizados para el coste, seleccionados en función de cada caso de uso.
03 · Validación reglamentaria
Anticiparse a las preguntas de BSI, del departamento interno de cumplimiento normativo y de los auditores, y documentar las decisiones y la arquitectura en el momento en que se adoptan.
04 · Industrialización
Diseñar lo que un equipo de operaciones realmente necesita para mantener la solución en producción durante cinco años, y no solo lo que el promotor necesita para la puesta en marcha.
La baja tasa de abandono como variable operativa, no como un motivo de orgullo
En el ámbito de la inteligencia artificial, la continuidad es aún más importante que en otras tecnologías, ya que parte del conocimiento del proyecto se encuentra fuera de los documentos: en las decisiones descartadas, en los sesgos de datos identificados y en las conversaciones con los departamentos comerciales y de cumplimiento normativo. Una empresa colaboradora con una alta tasa de rotación pierde ese conocimiento cada vez que se marcha un perfil. Una empresa colaboradora con una baja tasa de rotación lo acumula.
Para una empresa de servicios públicos que esté planificando una hoja de ruta de IA para un periodo de entre tres y cinco años, esta diferencia no es un simple detalle de recursos humanos del proveedor: es una variable operativa que afecta directamente al coste total de propiedad y al riesgo del programa.
Dónde encaja Principal33
En Principal33, los proyectos de IA en las empresas de servicios públicos alemanas son dirigidos y ejecutados por consultores sénior de principio a fin. No se produce ningún traspaso de responsabilidades de un equipo comercial a un equipo junior tras la firma del contrato. El mismo perfil que participa en la fase de análisis inicial está presente en la arquitectura, en la validación normativa y en la industrialización. Este modelo se sustenta en una tasa de rotación muy baja, respaldada por la política interna de desarrollo «sénior + junior» y por la especialización exclusiva en el mercado DACH.
Los equipos están formados por profesionales con amplia experiencia, de habla alemana y ubicados en la región DACH (Alemania, Austria y Suiza), lo que reduce el riesgo de malentendidos normativos y agiliza la toma de decisiones con los departamentos de TI, cumplimiento normativo y el área de negocio de la empresa de servicios públicos.
El cambio de perspectiva
Para una empresa de servicios públicos alemana que está evaluando socios para su estrategia de IA, la pregunta relevante no es «¿cuántos científicos de datos tenéis?». Casi todo el mundo dirá que muchos. La pregunta que permite anticipar el éxito o el fracaso del programa es menos cómoda: «¿Quién va a decidir dónde tiene cabida la IA y dónde no, y quién lleva años tomando ese tipo de decisiones en las empresas de servicios públicos alemanas?». La respuesta a esa pregunta es lo que distingue a un proyecto piloto prometedor de un programa de IA que llega a la fase de producción y se consolida.
