Secuenciar la conversión con la IA como criterio: qué limpiar primero

No toda deuda técnica bloquea la IA por igual

Cuando un comité de utilities o de O&G aprueba limpiar el core antes de activar IA, la instrucción que suele salir de esa reunión es “hay que limpiar todo antes de seguir”. Es la instrucción equivocada. No todo objeto de código personalizado bloquea a Joule con la misma severidad, y tratar la limpieza del core como un bloque monolítico —en vez de una secuencia priorizada— es la forma más común de que un proyecto de gobierno de datos se estire sin fecha de cierre.

La pregunta operativa no es “¿cuánto hay que limpiar?”, sino “¿en qué orden, y con qué criterio de IA en mente?”.

El criterio que ordena la limpieza: cuatro niveles, un solo destino

SAP formalizó esa respuesta en el modelo de niveles de clean core (Clean Core Level Concept), que clasifica cada extensión personalizada en cuatro niveles según qué tan acoplada está al núcleo y qué tan segura es frente a una actualización (IgniteSAP, 2026). El Nivel A cubre extensiones construidas exclusivamente con APIs liberadas y estables, ya sea on-stack con ABAP Cloud o side-by-side en BTP: es upgrade-safe y el objetivo de todo desarrollo nuevo. El Nivel B usa APIs clásicas de SAP, documentadas y generalmente estables, aceptable bajo gobernanza con monitoreo. El Nivel C accede a objetos internos de SAP, conlleva un riesgo de actualización significativo y pertenece a una hoja de ruta de remediación documentada, no a la arquitectura permanente. El Nivel D —modificaciones, enhancements implícitos y escrituras directas sobre tablas SAP— genera una exposición severa frente a cada actualización y, dondequiera que exista, requiere un cronograma de retiro (IgniteSAP, 2026).

Ese orden —D primero, C con hoja de ruta, B bajo gobernanza, A como destino— es exactamente la secuencia que convierte la limpieza del core en un proyecto con hitos, en vez de una intención sin cronograma.

El inventario antes que el roadmap

La secuencia solo funciona si arranca con un inventario real, no con la intuición de qué “parece” viejo o riesgoso. Antes de decidir qué remediar, eliminar o reconstruir en BTP, el paso obligatorio es un inventario completo y una clasificación de cada objeto personalizado contra los cuatro niveles de acoplamiento al núcleo (SAVIC Technologies, 2026). Sin ese inventario, cualquier plan de limpieza es una lista de sospechas, no una hoja de ruta: se termina remediando lo más visible o lo más reciente, no lo que efectivamente bloquea la IA.

Esto es particularmente relevante porque, en 2026, el clean core dejó de ser una guía aspiracional para convertirse en un prerequisito de negocio: los agentes de Joule y las funciones de IA embebida dependen de modelos de datos estandarizados y procesos limpios, y las personalizaciones pesadas rompen el contexto que esos agentes necesitan para funcionar (SAVIC Technologies, 2026).

Dónde vive, en la práctica, un objeto de Nivel C o D

El modelo de cuatro niveles es abstracto hasta que se aterriza en el sistema real. Y en el meter-to-cash de utilities y O&G, ese aterrizaje casi nunca es un desarrollo espectacular: es el objeto silencioso que nadie clasificó, porque “siempre funcionó así”.

Un agente de IA no distingue entre un objeto “legado pero inofensivo” y uno que efectivamente rompe la lectura de datos aguas abajo: para el agente, ambos son ruido si el dato que reciben no es confiable. Por eso clasificar estos tres puntos contra el modelo de niveles —no tratarlos como una lista plana de fricciones operativas— es lo que decide si entran a una hoja de ruta de remediación con prioridad, o si se quedan en un backlog de “mejoras deseables” que nunca se prioriza.

Priorizar la remediación de esos puntos concretos —antes que reconstruir procesos que ya funcionan de forma estándar— es lo que separa un proyecto de clean core que efectivamente habilita IA en el meter-to-cash de uno que consume presupuesto sin mover la aguja en los casos de uso que la dirección realmente quiere ver funcionando.

Siguiente paso: gobernar la expectativa sin demo visible

Secuenciar la limpieza del core con este criterio resuelve la pregunta operativa de qué hacer primero. Lo que queda sin resolver es la pregunta de gestión: cómo sostener la conversación con el directorio durante los meses en los que este trabajo de remediación no produce ninguna demo visible de IA. Ese es el tema de la siguiente pieza de esta serie.

Fuentes

• SAVIC Technologies, SAP Clean Core Strategy 2026 — Practical Guide for Enterprises (2026)
• IgniteSAP, SAP’s Clean Core in Practice (2026)
• SAPinsider, SAP Sapphire 2026: What Four Global Enterprises Taught Us About AI-Driven Transformation (2026)