Conecta Kiro con SAP para documentar y generar código ABAP
Este post muestra a equipos técnicos SAP cómo usar Kiro con el ABAP Accelerator MCP y el SDK ABAP Knowledge MCP para leer código fuente de sistemas SAP vía ADT, automatizar documentación ABAP a escala, generar reportes ALV, ejecutar validaciones de calidad con ATC y analizar la preparación para migración de ECC a S/4HANA, todo desde un solo IDE.
Introducción
Si trabajas con código ABAP, Kiro te ofrece acceso directo al código fuente de tu sistema SAP a través de ADT (ABAP Development Tools). Kiro es el IDE agéntico de AWS, un entorno de desarrollo donde un agente de IA lee tu código, planifica los cambios y ejecuta acciones de desarrollo bajo tu supervisión.
En este post mostramos cómo conectar Kiro a SAP mediante MCP para documentar, generar y validar código ABAP directamente desde el IDE, y cómo aplicar las capacidades de Kiro (Specs, Hooks y Steering) a escenarios reales para equipos técnicos que desarrollan en SAP.
Tres capacidades diferencian a Kiro de un asistente de autocompletado. Los Specs permiten un diseño iterativo con trazabilidad completa, donde el flujo va de requirements a design, luego a tasks y finalmente a la implementación, manteniendo el hilo de principio a fin. Los Hooks automatizan flujos al guardar un archivo, al hacer commit o al terminar una tarea, sin intervención manual. El Steering codifica los estándares de calidad del equipo (convenciones de código, reglas de modularización y buenas prácticas) y los aplica de forma activa en cada interacción con el agente.
A estas tres capacidades se suma el soporte nativo para MCP (Model Context Protocol), el estándar que conecta el agente a sistemas externos. Aquí es donde SAP entra en la ecuación.
Kiro opera con autonomía supervisada: el agente propone, ejecuta y valida, pero tú mantienes el control en todo momento. Está disponible gratis en kiro.dev .
El problema: SAP sin contexto
Quienes trabajamos con código ABAP y usamos un IDE genérico con IA ya conocemos la limitación: el agente no sabe nada de nuestro sistema. No conoce nuestros programas Z, nuestras transformaciones BW, nuestras tablas custom ni la lógica de negocio que lleva años acumulándose sin documentación.
En el día a día de un equipo SAP aparecen tres problemas recurrentes. El primero es la documentación inexistente: programas Z escritos hace años, sin comentarios ni descripción funcional, donde solo la persona que los escribió sabe qué hacen (si es que sigue en la empresa). El segundo es la lógica embebida en transformaciones BW, con rutinas de inicio, fin y mapeo de campos en código ABAP que no es visible desde la interfaz gráfica del sistema; quien hereda esas rutinas se enfrenta a semanas en revisión de código. El tercero es la migración sin visibilidad: pasar de ECC a S/4HANA o migrar BW exige inventariar lógica compleja dispersa en cientos de objetos.
Siempre podemos descargar ese código y pegarlo en una IA para que nos explique qué hace. Pero eso nos deja como intermediarios: copiamos, pegamos, procesamos y descartamos. Un agente de IA genérico responde con patrones generales de ABAP, lo cual es útil para aprender, pero insuficiente para producir trabajo real sobre nuestro sistema.
Y seamos honestos: no hay nada peor que volver a ver un código que escribiste hace años. O quizá sí lo hay: tomar el código ABAP de alguien más.
El salto que propone Kiro es distinto. Con Kiro y el ABAP Accelerator, el agente no se limita a explicar el fragmento que pegaste. Genera documentación a múltiples niveles de profundidad y entiende las dependencias entre programas, entre funciones y entre tablas. No produce una explicación aislada, sino un mapa del sistema. Pasas de intermediario a contar con un colaborador que entiende el contexto completo de tu SAP.
MCP: el puente entre Kiro y SAP
MCP (Model Context Protocol) es un estándar abierto creado por Anthropic en 2024. Define cómo un agente de IA se conecta a sistemas externos para obtener contexto en tiempo real.
La siguiente tabla compara el comportamiento del agente con y sin MCP:
| Sin MCP | Con MCP |
|---|---|
| Agente genérico con conocimiento de entrenamiento | Agente contextualizado con acceso al sistema SAP |
| No sabe nada de tu código Z | Lee código fuente directamente desde SAP |
| Respuestas genéricas | Respuestas basadas en tu contexto real |
| No puede validar contra tu sistema | Ejecuta ATC, syntax check y unit tests en vivo |
MCP funciona como un protocolo estándar: cualquier agente compatible puede conectarse a cualquier sistema que exponga un servidor MCP. Kiro lo soporta de forma nativa.
Los MCP para equipos técnicos SAP
Para desarrollo ABAP hay dos servidores MCP relevantes, que cubren necesidades complementarias.
El ABAP Accelerator da acceso al código fuente SAP vía ADT. Permite documentar, crear, probar y transformar código ABAP directamente desde Kiro, porque el agente lee el código en tiempo real del sistema SAP y no trabaja con archivos locales ni suposiciones. Se ejecuta localmente (con Python o Docker) o en Amazon Elastic Container Service (Amazon ECS) con AWS Fargate para equipos completos. Se conecta al SAP mediante el protocolo REST de ADT sobre HTTP/HTTPS y no tiene costo, ya que la imagen Docker es descargable. En modo local es extensible: puedes pedirle a Kiro que construya nuevas herramientas adaptadas a tu caso de uso, como la trazabilidad de lógicas en transformaciones SAP BW (rutinas de inicio, fin, reglas de mapeo y dependencias entre objetos), generada como una herramienta nueva dentro de tu MCP local.
El SDK ABAP Knowledge es la base de conocimiento del AWS SDK for SAP ABAP . Genera código ABAP sintácticamente correcto para integrar servicios de AWS como Amazon Simple Storage Service (Amazon S3), Amazon Bedrock y Amazon DynamoDB, entre más de 200 servicios, desde código ABAP. Para entender cómo se integra con IDEs agénticos, recomendamos leer Extend agentic IDEs with AWS SDK for SAP ABAP documentation . Es un endpoint público que solo hay que agregar al
mcp.json (la URL exacta está en el Paso 2), no requiere autenticación ni instalación, se actualiza a diario en sincronía con los releases del SDK y expone más de 80,000 páginas de documentación ABAP que el agente consulta en tiempo real.Specs, Hooks y Steering aplicados a SAP
Antes de entrar en los casos de uso, conviene ver cómo se materializan en SAP las tres capacidades que diferencian a Kiro. Cada una se configura con archivos sencillos dentro del proyecto y se aplica a tareas concretas de desarrollo ABAP.
Steering: codificar el estándar ABAP del equipo
El Steering son archivos markdown que viven en
.kiro/steering/ y acompañan cada interacción del agente. Sirven para fijar convenciones de código, reglas de negocio y buenas prácticas. Un archivo de Steering puede incluirse siempre, de forma condicional según el archivo abierto, o de forma manual.El siguiente ejemplo define un estándar ABAP que el agente respeta al generar o modificar código:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
inclusion: always
# Estándar ABAP del equipo
## Nomenclatura
- Variables locales con prefijo `lv_`, tablas internas con `lt_`, estructuras con `ls_`.
- Clases custom con prefijo `ZCL_`, interfaces con `ZIF_`.
## Modularización
- Métodos de máximo 50 líneas. Si crece más, dividir.
- Preferir clases ABAP Objects sobre programas con includes legacy.
## Comentarios
- Cada método lleva una cabecera con propósito, parámetros y autor.
- Documentar la lógica de negocio, no la sintaxis.Una vez guardado, el agente sigue estas reglas en todo el proyecto sin que haya que repetirlas en cada prompt.
Hooks: automatizar la calidad sin intervención manual
Los Hooks ejecutan una acción del agente cuando ocurre un evento en el IDE. Para un equipo SAP, esto permite disparar validaciones automáticas al guardar un archivo ABAP o al terminar una tarea.
El siguiente Hook ejecuta una revisión con ATC cada vez que se guarda un archivo
.abap:1
2
3
4
5
6
7
8
9
10
11
12
{
"name": "Validar ABAP al guardar",
"version": "1.0.0",
"when": {
"type": "fileEdited",
"patterns": ["*.abap"]
},
"then": {
"type": "askAgent",
"prompt": "Ejecuta ATC y syntax check sobre el archivo guardado y corrige los errores de severidad Error."
}
}También se puede automatizar al cierre de cada tarea de un Spec, usando el evento
postTaskExecution, para que el agente genere o ejecute los unit tests ABAP antes de marcar la tarea como completada.Specs: del requerimiento a la implementación con trazabilidad
Un Spec estructura el trabajo en tres documentos dentro de
.kiro/specs/: requirements.md captura qué se necesita, design.md define cómo se implementa y tasks.md desglosa el trabajo en tareas ejecutables. El agente recorre ese flujo manteniendo la trazabilidad de principio a fin.Para crear un Spec de documentación masiva de programas Z, le describes el objetivo a Kiro en lenguaje natural y el agente propone primero los requirements. Un extracto de
requirements.md podría verse así:1
2
3
4
5
6
7
8
9
10
# Requirements: documentación de programas Z del módulo MM
## Requirement 1: inventario
COMO equipo de migración
QUIERO un inventario de los programas Z del paquete ZMM
PARA priorizar la documentación por complejidad.
### Criterios de aceptación
1. CUANDO se ejecute la tarea ENTONCES se listarán todos los programas Z del paquete con líneas de código y dependencias.
2. CUANDO un programa supere 1,000 líneas ENTONCES se marcará como alta complejidad.Tras tu aprobación, Kiro genera el
design.md con el formato de salida y los niveles de anidamiento, y luego el tasks.md con una tarea por programa. A partir de ahí, el agente ejecuta las tareas una por una y produce documentación consistente para todo el paquete.Casos de uso concretos
Las capacidades anteriores cobran sentido al aplicarlas a problemas reales de un equipo SAP. A continuación recorremos cuatro escenarios donde Kiro y los MCP de SAP aportan valor inmediato: documentación de programas Z, generación de ALVs, barrido de calidad de código y análisis de migración.
Documentación automática de programas Z
Este es probablemente el caso de uso que más nos entusiasma, porque ataca un dolor que casi todos hemos vivido: volver a código que escribimos hace años o, peor aún, heredar el código de otra persona.
Documentar programas Z no consiste en apuntar al sistema y decir "documenta todo". Existe una metodología iterativa que funciona y que queremos compartir, organizada en tres fases.
Fase 1, vibe coding: armar el framework de documentación. Antes de documentar un solo programa, hay que definir qué documentar y para qué. Esto se hace en modo conversacional con Kiro. Primero se fija el objetivo, porque no es lo mismo documentar para migrar dentro de SAP (de ECC a S/4HANA, con foco en clean core) que para migrar fuera de SAP y reescribir en otro lenguaje. Luego se identifican los datos críticos; una buena práctica es pedirle a Kiro que busque en internet qué es lo más relevante a documentar en un programa ABAP y después personalizarlo con el contexto del cliente, como las tablas utilizadas, la cantidad de líneas de código y las líneas comentadas. También se definen los niveles de anidamiento que conviene explorar, ya que un programa referencia funciones, tablas y otros programas, y no siempre conviene llegar al máximo. Por último se elige el formato de salida: markdown, tabla, Word o integración con el sistema de documentación existente del cliente.
Fase 2, iteración: validar y ajustar. Con el framework definido, lo probamos contra programas de distintos niveles de complejidad: uno básico, uno mediano y uno con muchas dependencias. Cada iteración ajusta el proceso y el resultado hasta que el output sea consistente y útil.
Fase 3, spec-driven: documentación masiva. Una vez validado el framework, armamos un Spec en Kiro (requirements, design y tasks) para documentar paquetes enteros de programas Z. La agrupación depende de lo que más le sirva al cliente, ya sea por módulo SAP, por paquete de desarrollo o por equipo responsable. El agente ejecuta las tareas una por una y genera documentación consistente para todo el grupo.
📄 Ejemplo real: enFRAMEWORK_DOCUMENTACION_ABAP_Z_AWS.mdcompartimos un framework completo armado con Kiro. Incluye las 12 secciones que usamos para documentar programas Z con foco en migración y modernización en AWS, desde la identificación y métricas de código, pasando por el análisis de ABAP Cloud Readiness, hasta la arquitectura target en AWS con un plan de acción en fases.📋 Output de ejemplo: enZORDERTOCASH.mdmostramos el resultado de aplicar ese framework a un programa real. El código fuente original está enZORDERTOCASH_source.md, así puedes ver de primera mano el input y el output del proceso.
El siguiente diagrama resume las tres fases de la metodología de documentación:
Metodología de documentación en 3 fases
Generación de ALVs con capa semántica
Las tablas de SAP tienen nombres que no son fáciles de entender. Para obtener una salida legible para el negocio hay que unir múltiples tablas y construir una capa semántica encima, lo que requiere conocimiento profundo del modelo de datos SAP.
Con Kiro, ese proceso cambia. En lugar de construir el ALV tabla por tabla, le pedimos al agente en lenguaje natural lo que necesitamos:
"Ayúdame a generar un ALV donde pueda ver end-to-end el ciclo de compras: desde Solped, Orden de Compra, Recepción de materiales y servicios, hasta el pago. Con columnas descriptivas, no nombres técnicos."
Con acceso al sistema vía el ABAP Accelerator, Kiro identifica las tablas involucradas (EBAN, EKKO, EKPO, MSEG, BKPF, BSEG) y construye los JOINs. Luego genera columnas con descripciones legibles y produce el programa ABAP completo.
Las siguientes capturas muestran la generación del ALV en Kiro y su ejecución final en SAP:
Barrido de calidad de código
El código que genera Kiro no sale solo al mundo. Desde el IDE, el agente puede ejecutar validaciones de calidad de inmediato: una revisión con ATC (ABAP Test Cockpit) que entrega resultados por severidad (Error, Warning, Info), un syntax check para verificar la compilación y la ejecución de unit tests ABAP existentes o la generación de nuevos. Todo esto ocurre sin abrir Eclipse ni SAP GUI, porque el ciclo completo de generación y validación sucede dentro de Kiro, sin cambiar de herramienta.
El nivel siguiente es usar el Steering como estándar de equipo, tal como vimos antes. Kiro permite definir un archivo de Steering que codifica el estándar de calidad del cliente: convenciones de nombres, estructura de comentarios, reglas de modularización y uso de clases frente a programas legacy. Ese Steering acompaña cada interacción del agente con el equipo, no como una revisión posterior, sino como una guía activa durante el desarrollo. Así el comportamiento del equipo se vuelve más consistente.
Análisis de migración ECC → S/4HANA
El ABAP Accelerator incluye la herramienta
get_migration_analysis, que analiza código ABAP e identifica incompatibilidades con S/4HANA, como tablas obsoletas, funciones deprecadas y patrones que violan clean core. El alcance del análisis está definido en la documentación del repositorio del ABAP Accelerator, lo que lo hace auditable y extensible. El agente propone la conversión y la valida con ATC dentro del mismo flujo.Extensibilidad: crear tus propias herramientas con Kiro
El ABAP Accelerator no cubre todos los escenarios, y no tiene por qué hacerlo. El MCP en modo local es extensible, y Kiro puede construir esa extensión por ti.
Veamos un ejemplo concreto: la trazabilidad de lógicas en transformaciones SAP BW. El ABAP Accelerator no incluye herramientas nativas para BW, pero eso es una oportunidad más que un límite. Le pides a Kiro que construya una nueva herramienta que extraiga y trace la lógica completa de una transformación, con sus rutinas de inicio, rutinas de fin, reglas de mapeo de campos y dependencias entre objetos. Kiro genera la herramienta, la agrega a tu MCP local y, a partir de ahí, el agente la usa como cualquier otra.
Esto aplica a los casos de uso que tu equipo necesite y que el MCP base no cubra todavía, siempre que se puedan resolver con las APIs de ADT disponibles. La barrera no suele ser técnica, sino plantear el requerimiento.
Requisitos técnicos
La siguiente tabla resume los requisitos de cada MCP para equipos técnicos SAP:
| Componente | Requisito |
|---|---|
| ABAP Accelerator | |
| Versión SAP mínima | SAP NetWeaver 7.31 SP4+ con ADT habilitado |
| Versión recomendada | NW 7.50+ / S/4HANA (soporte completo: ATC, unit tests, RAP) |
| Roles SAP requeridos | SAP_BC_DWB_ABAPDEVELOPER + SAP_BC_TRANSPORT_OPERATOR |
| Servicios ICF | Nodo /sap/bc/adt/ activado en SICF |
| Entornos | Solo no-productivos: DEV, SBX, QAS, TST |
| Despliegue | Local Python, Docker, o Amazon ECS con AWS Fargate |
| Conectividad | HTTP/HTTPS desde el servidor MCP hacia el SAP |
| Tiempo de setup | Aproximadamente 15 a 30 minutos en local (estimación según el entorno) |
| SDK ABAP Knowledge | |
| Versión SAP | NW 7.4+ (para usar el SDK subyacente en el sistema) |
| Instalación | Solo agregar URL al mcp.json |
| Autenticación | Ninguna, endpoint público |
| Costo | Gratis |
La siguiente captura muestra los roles SAP requeridos vistos en la transacción SU01:
Sobre los roles, conviene entender qué habilita cada uno. El rol
SAP_BC_DWB_ABAPDEVELOPER da acceso al código fuente vía ADT. El rol SAP_BC_TRANSPORT_OPERATOR permite crear objetos, asignarlos y liberar transport requests en el sistema de desarrollo. El MCP cubre hasta la liberación de TRs; el ciclo de transporte entre sistemas (de DEV a QAS y a PRD) queda fuera, como corresponde a una herramienta enfocada en entornos no-productivos.Regla práctica: si tu equipo ya usa Eclipse con ADT para desarrollar, el ABAP Accelerator puede conectarse sin cambios. Si solo usan SAP GUI (SE80), Basis debe activar los servicios ICF de ADT y asignar los roles correspondientes.
Cómo empezar hoy
Paso 1: instalar Kiro
Descarga Kiro desde kiro.dev . La instalación es estándar y funciona en Windows, macOS y Linux.
Paso 2: configurar SDK ABAP Knowledge
Este MCP es el más rápido de habilitar. Abre
~/.kiro/settings/mcp.json y agrega la siguiente configuración:1
2
3
4
5
6
7
8
9
{
"mcpServers": {
"abap-sdk-knowledge": {
"url": "https://sdk-for-sap-abap-knowledge-mcp.global.api.aws/mcp",
"disabled": false,
"autoApprove": ["*"]
}
}
}Funciona de inmediato, sin autenticación ni instalación adicional. Para comprobarlo de extremo a extremo, abre Kiro y pídele en lenguaje natural que genere código ABAP que suba un archivo a Amazon S3 usando el AWS SDK for SAP ABAP. El agente consulta la documentación a través del MCP y devuelve el código sintácticamente correcto, listo para revisar.
Paso 3: configurar ABAP Accelerator (si tienes acceso a SAP DEV)
Este MCP requiere unos pasos más, porque se conecta a tu sistema SAP. El procedimiento de extremo a extremo es el siguiente:
- Clona el repositorio
guidance-for-deploying-sap-abap-accelerator-for-amazon-q-developer. - Configura las credenciales de forma segura (host SAP, cliente y usuario).
- Inicia el servidor con
.venv/bin/python src/aws_abap_accelerator/main.py. - Agrega la entrada del ABAP Accelerator local a tu
mcp.jsonde Kiro:
1
2
3
4
5
6
7
8
9
{
"mcpServers": {
"abap-accelerator": {
"url": "http://localhost:8000/mcp",
"disabled": false,
"autoApprove": ["*"]
}
}
}- Verifica el flujo completo: abre Kiro, pídele que documente un programa Z conocido y confirma que el agente lee el código fuente del sistema y devuelve la documentación. Con eso queda validado que Kiro, el MCP y SAP están conectados.
Para las credenciales hay tres alternativas, resumidas en la siguiente tabla:
| Método | Cómo funciona | Cuándo usarlo |
|---|---|---|
Archivo .env | Variables en un archivo que el MCP lee al iniciar. Agregar .env al .gitignore. | Recomendado para local, directo y seguro |
| Variables de entorno del OS | export SAP_HOST=... en la sesión del shell | Más seguro (no queda en disco) pero menos cómodo |
Docker --env-file | docker run --env-file .env abap-accelerator | Si usas el contenedor |
⚠️ No dejes credenciales SAP en el archivomcp.json. Ese archivo suele estar en el repositorio del proyecto. Usa siempre.envo variables de entorno.
💡 Tip: puedes pedirle a Kiro que configure esto por ti: "Crea un archivo .env para el ABAP Accelerator con las variables SAP_HOST, SAP_CLIENT, SAP_USER y SAP_PASSWORD, y agrégalo al .gitignore". Kiro crea la estructura, el
.gitignore y valida la conexión.Como recomendación de seguridad, crea un usuario técnico SAP dedicado para el MCP, con solo los dos roles requeridos y apuntando exclusivamente a DEV o SBX.
Documentación completa
La referencia completa está en docs.aws.amazon.com/mcp-sap .
Limpieza de recursos
Cuando termines de probar el ABAP Accelerator, conviene revertir la configuración para no dejar el servidor MCP ni las credenciales activos. Sigue estos pasos para limpiar el entorno.
- Detén el servidor MCP. Si lo ejecutas con Python en local, detén el proceso
main.py(conCtrl+Cen la terminal donde corre). Si usas Docker, detén y elimina el contenedor condocker stop abap-acceleratory luegodocker rm abap-accelerator. Si lo desplegaste en Amazon ECS con AWS Fargate, reduce el servicio a cero tareas o elimina el stack que lo creó. - Quita la configuración del
mcp.json. Abre~/.kiro/settings/mcp.jsony elimina la entradaabap-acceleratordel ABAP Accelerator (el bloque que apunta a tu servidor local en el puerto 8000). Haz lo mismo con la entradaabap-sdk-knowledgesi ya no la necesitas. Kiro recarga la configuración sin reiniciar. - Elimina las credenciales locales. Borra el archivo
.envcon las variables de SAP y, si exportaste variables de entorno en el shell, ciérralo o usaunsetpara cada una. - Revisa el usuario técnico SAP. Si creaste un usuario dedicado para el MCP, bloquéalo o elimínalo en SU01 cuando ya no lo uses, junto con los roles asignados para esta prueba.
Tras estos pasos, Kiro vuelve a operar sin acceso al sistema SAP y no queda ninguna credencial en disco.
Consideraciones
Antes de implementar, ten en cuenta tres puntos. El ABAP Accelerator está diseñado exclusivamente para entornos no-productivos (DEV, SBX, QAS, TST) y no debe usarse en sistemas productivos. En cuanto a la política de APIs de SAP de abril de 2026, SAP publicó una política que restringe el uso de APIs para agentes de IA autónomos fuera de "arquitecturas aprobadas"; el ABAP Accelerator usa ADT, que son APIs documentadas de SAP, y su uso en entornos de desarrollo reduce el riesgo, pero conviene consultar con SAP y con el equipo legal de tu organización antes de implementar integraciones en ambientes no-DEV. Por último, Kiro no reemplaza al desarrollador SAP, sino que le da más contexto y velocidad, y el control sigue siendo del equipo técnico.
Arquitectura: Kiro + ABAP Accelerator MCP
El siguiente diagrama muestra cómo Kiro se conecta al sistema SAP a través del ABAP Accelerator MCP:
Arquitectura: Kiro + MCP para SAP
El flujo de trabajo recorre cuatro pasos. Primero, el developer trabaja en Kiro y escribe un prompt, por ejemplo "documenta este programa Z". Segundo, Kiro invoca el ABAP Accelerator MCP vía HTTP local (o remoto en Amazon ECS con AWS Fargate). Tercero, el ABAP Accelerator se conecta al sistema SAP mediante el protocolo ADT (REST sobre HTTPS) y lee o escribe objetos ABAP. Cuarto, en paralelo, el SDK ABAP Knowledge MCP aporta el conocimiento para generar código ABAP que integre servicios de AWS como Amazon S3, Amazon Bedrock y Amazon DynamoDB.
La siguiente tabla compara las opciones de despliegue del ABAP Accelerator:
| Opción | Dónde se ejecuta | Auth SAP | Ideal para |
|---|---|---|---|
| Python local | Laptop del developer | Archivo .env | Pruebas rápidas |
| Docker local | Laptop (contenedor) | --env-file | Multi-sistema, aislado |
| Amazon ECS con AWS Fargate | AWS (contenedor gestionado) | Principal Propagation + OAuth 2.0 | Equipo completo |
Documentación completa de arquitectura: docs.aws.amazon.com/mcp-sap
Sobre los autores
Francisco Fagas es Senior Specialist Solutions Architect para IA Generativa en AWS, basado en San Juan, Puerto Rico, cubriendo cuentas enterprise de LATAM NOLA. Con más de 20 años de experiencia en TI, combina un profundo conocimiento técnico en arquitectura de nube, desarrollo de aplicaciones e IA/ML para ayudar a clientes enterprise a adoptar IA Generativa y acelerar la innovación mediante IA agéntica, grandes modelos de lenguaje y prácticas modernas de desarrollo.
Rosmar Torres es Solutions Architect en AWS Chile, cubriendo cuentas enterprise. Con 9 años de experiencia en SAP BW/HANA y SAP Analytics, combina un profundo conocimiento de SAP con un fuerte enfoque en IA Generativa para ayudar a los clientes a acelerar sus procesos de adopción de nube y modernización. Creó esta adaptación como una contribución personal, a partir de su experiencia práctica acompañando a múltiples clientes en engagements de arquitectura en Chile.
Sobre los revisores
César Andrés Páez Román es Senior Migrations and Modernization Solutions Architect en AWS Chile, cubriendo cuentas enterprise de LATAM. Con 15 años de experiencia en infraestructura SAP (S/4HANA, ERP, Business Suite on HANA, Netweaver) y migraciones a la nube, combina un profundo conocimiento técnico de SAP con un fuerte enfoque en ayudar a los clientes a acelerar sus procesos de adopción de nube y modernización a nivel ejecutivo. Creó esta adaptación como una contribución personal, a partir de su experiencia práctica liderando engagements de migración y modernización en múltiples clientes en Chile y LATAM.
Felipe Chirinos es Solutions Architecture Manager para AWS, basado en Santiago de Chile. Tiene más de 15 años de experiencia en soluciones de tecnología en la región y está certificado como AWS Solutions Architect Professional.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article