Programa de seis semanas para equipos técnicos
Que el equipo desarrolle con IA y con controles que se pueden medir, antes y después
Seis semanas con un diagnóstico de las configuraciones de IA, el workshop completo, un informe para dirección con cinco acciones priorizadas y una segunda medición con los números del propio equipo. No prometo un porcentaje de mejora. Lo que cambie, lo dejo medido.
En remoto y en presencial, en español o en inglés. Para equipos que ya usan Claude Code o GitHub Copilot sobre repositorios reales. La propuesta se cierra después de una llamada.
Bonificable a través de FUNDAE.
El problema de partida
Un día de formación cambia lo que el equipo sabe, pero lo que hace no siempre.
Al volver de un workshop, cada uno vuelve a su rama, a su plazo y a sus hábitos. Si nadie mira qué se aplicó, a las tres semanas queda un buen recuerdo y pocas configuraciones cambiadas. Con IA pesa más: los asistentes, los servidores MCP y los modos de autonomía se actualizan cada pocos meses y lo que se decidió ayer caduca.
Hay un segundo problema: la sensación de ir más rápido no es una medida. En 2025 un ensayo aleatorizado de METR con desarrolladores experimentados midió que tardaban más con IA y que ellos creían haber ido más rápido. Por eso mido al principio y al final en vez de prometer cómo irá.
El programa junta tres cosas que suelen comprarse por separado: el día de formación, el seguimiento posterior y la evidencia que pide quien audita. Al final, la empresa tiene cambios en el repositorio, un informe que enseñar a dirección y dos mediciones para compararlas.
Qué cambia al terminar
Cinco resultados que se pueden enseñar a quien decide
Cada resultado tiene un entregable concreto y una semana en la que aparece. Lo que no puedo prometer es cuánto valdrán los indicadores. Eso depende de los datos del equipo.
- 01
Saber desde qué punto parte el equipo
Con una encuesta de diez minutos al equipo y la revisión de las configuraciones de IA que ya hay en los repositorios, queda por escrito qué lee el asistente, qué tiene conectado y qué puede ejecutar.
Prueba: ficha de diagnóstico y medición inicial con 4 a 6 indicadores acordados. - 02
Salir del workshop con controles en el repositorio
En el último bloque cada participante aplica los controles sobre el código de la empresa. Las configuraciones quedan en una rama de su repositorio y la fusiona el equipo.
Prueba: rama con configuraciones, política técnica de uso de IA y MCP, y Definition of Done. - 03
Tener evidencia para el control y algo más que el recuerdo de un curso
Asistencia firmada, certificado individual y un temario mapeado a las normas que apliquen a la empresa, con una carta de una página para quien audite.
Prueba: paquete de evidencia entregado la misma semana del workshop. - 04
Darle a dirección un documento que se pueda leer
Qué se vio, qué se trabajó, qué riesgos aparecieron en las configuraciones y cinco acciones con responsable. No es una auditoría y el informe lo dice en la primera página.
Prueba: informe de 3 a 5 páginas en la semana 2. - 05
Comprobar qué se aplicó de verdad
A las seis semanas repetimos los indicadores y vemos con el equipo qué se mantiene, qué se abandonó y qué hay que ajustar.
Prueba: comparativa del antes y el después con los números del equipo.
Las fases
Qué pasa cada semana y quién lo hace
Casi todo el trabajo lo hago sin que el equipo tenga que parar. Pido tiempo en dos momentos: la encuesta, de diez minutos por persona, y el día del workshop.
Diagnóstico y medición inicial
El equipo contesta una encuesta de diez minutos. Yo miro las configuraciones de IA que ya hay en los repositorios y acordamos entre cuatro y seis indicadores. Con eso adapto los laboratorios al stack del equipo.
Entregable: Ficha de diagnóstico y medición inicial.Workshop y paquete de evidencia
Doy el workshop completo, de 5 a 8 horas según el equipo, con el último bloque sobre el repositorio de la empresa. Cada participante firma la asistencia y al acabar el día preparo la evidencia del curso.
Entregable: Rama con configuraciones, política técnica de uso de IA y MCP, paquete de evidencia.Informe a dirección
Escribo un documento de tres a cinco páginas para quien decide, con lo que salió en el diagnóstico, lo que trabajamos en el workshop y cinco acciones priorizadas con un responsable propuesto para cada una. No es una auditoría.
Entregable: Informe de 3 a 5 páginas.Canal de dudas y revisión de pull requests
Abrimos un canal en el Slack o Teams de la empresa y respondo en dos días laborables. El equipo me manda dos o tres pull requests reales y los comento por escrito, en la plataforma de la empresa y con sus permisos, o con fragmentos si la empresa lo prefiere. El canal se cierra al terminar la semana 5.
Entregable: Revisión escrita de dos o tres pull requests.Revisión remota y segunda medición
Noventa minutos en remoto con el equipo para ver qué se aplicó, qué no y por qué. Repetimos los indicadores y ajustamos las configuraciones que lo necesiten.
Entregable: Comparativa del antes y el después.
La semana 1 es el workshop completo, con su temario y sus prácticas: Desarrollo seguro con IA
Medir en lugar de prometer
Cómo saber si ha servido
En 2025 un ensayo aleatorizado de METR con desarrolladores experimentados de código abierto midió que tardaban un 19 % más con IA y que ellos creían haber ido un 20 % más rápido. Son herramientas de principios de 2025 y no dice nada de un equipo concreto, pero enseña que la impresión no vale como medida. Por eso no prometo un porcentaje. Elegimos juntos los indicadores que sirvan a la empresa, y estos son candidatos.
Pull requests con código generado revisados con la lista
Qué parte de los cambios hechos con asistente pasa por la lista de revisión acordada.
Hallazgos de SAST y de secretos por pull request
Lo que ya detectan las herramientas del equipo, contado antes y después, sobre el mismo tipo de cambios.
Tiempo de revisión de un pull request generado
Cuánto tarda una persona en aceptar o rechazar, medido en el sistema de control de versiones de la empresa.
Cambios en la configuración del asistente que pasan por revisión
Cuántas modificaciones de ficheros como mcp.json o los ajustes del IDE tienen revisión humana.
Inventario de MCP y Skills con responsable y justificación
Cuántos de los conectados tienen alguien que responda de ellos.
Confianza del equipo en el código generado
Una encuesta corta, repetida en la semana 6. Es una percepción y la trato como tal.
Curso o programa
| Necesidad | Workshop | Programa |
|---|---|---|
| Que el equipo aprenda a usar los asistentes con controles | Con el curso vale: entre 5 y 8 horas según el equipo, con el último bloque sobre el código de la empresa. | Añade diagnóstico previo y revisión posterior. |
| Una justificación documentada de la formación para una norma o una auditoría | El curso incluye el paquete de evidencia. | Suma el informe a dirección y la comparativa final. |
| Saber qué se aplicó y qué cambió al cabo de unas semanas | El curso no lo cubre. Eso lo decide la empresa. | Dos mediciones y una revisión a las seis semanas. |
| Un equipo que va a aplicar los controles solo y tiene tiempo para hacerlo | Es lo que hace falta. Si el equipo se atasca, la garantía de los 30 días cubre una hora. | No hace falta. |
Lo que se queda en la empresa
Lo que queda en la empresa seis semanas después
Además de todo el material del workshop, el programa deja documentos hechos para que circulen dentro de la empresa.
- Ficha de diagnósticoCómo están las configuraciones de IA al empezar y lo que contesta el equipo en la encuesta.
- Medición inicial y finalUna plantilla con los indicadores que elijamos juntos, rellenada en la semana 0 y repetida en la 6.
- Informe a direcciónDe tres a cinco páginas con cinco acciones priorizadas y quién responde de cada una.
- Paquete de evidenciaAsistencia firmada, certificados individuales, temario mapeado y carta de una página para el auditor.
- Revisión escrita de dos o tres pull requestsComentarios sobre cambios reales del equipo, con las pautas del workshop.
- Comparativa del antes y el despuésLo que se midió, lo que cambió y lo que no, tal cual.
Qué incluye
Todo lo del curso, y el resto del programa encima
El programa incluye el workshop y los cuatro bonus que van con él. Para explicar internamente qué incluye, esta lista es el mejor punto de partida.
- +1
Paquete de evidencia de cumplimiento
Asistencia firmada, certificado individual con fecha, horas y contenidos, temario mapeado a las normas que apliquen a la empresa y carta de una página para el auditor.
- +2
Encuesta previa de diez minutos al equipo
Me sirve para adaptar los laboratorios al stack del equipo y es la base de la medición inicial.
- +3
Configuraciones en una rama del repositorio de la empresa
Las dejo en el último bloque, junto con una plantilla técnica de política de uso de IA y MCP. Es técnica y no jurídica, así que la adapta el equipo legal de la empresa.
- +4
Repositorio de laboratorios con soluciones
Para repetirlos con quien se incorpore, con licencia de uso interno durante 12 meses.
Cumplimiento
Qué evidencia deja el programa y para qué controles sirve
El paquete sirve como evidencia para estos controles, pero no los cumple por sí solo. El control lo ejecuta y lo mantiene la empresa, y aquí se documenta la formación. En la llamada indico cuáles aplican a la empresa.
| Norma | Qué pide | Qué dejo como evidencia |
|---|---|---|
| PCI DSS 4.0 · 6.2.2 | Formación documentada, al menos cada 12 meses, para quien desarrolla software a medida, en seguridad relevante para su función y sus lenguajes. | Temario mapeado a los puntos del requisito, asistencia firmada y fecha. |
| ISO 27001:2022 · A.6.3 | Concienciación, educación y formación en seguridad adecuadas a la función de cada persona. | Registro por persona y rol, con contenidos y fecha. |
| ISO 27001:2022 · A.8.25 y A.8.28 | Ciclo de vida de desarrollo seguro y codificación segura, con formación de los desarrolladores. | Temario mapeado, Definition of Done y lista de revisión resultantes. |
| SOC 2 · CC1.4 y CC2.2 | Programa de formación documentado, con registro de finalización por persona y profundidad según el rol. | Lista con nombre, fecha, contenido y rol, y certificado individual. |
| DORA · art. 13(6) | Formación en resiliencia operativa digital proporcional a la función, para entidades financieras sujetas al reglamento. | Registro de la formación y temario, para el expediente de la empresa. |
| AI Act · art. 4 | Medidas para apoyar la alfabetización en IA del personal, adaptadas a su función y contexto. Es una obligación de medios y no exige certificado. | Registro interno de la formación, con contenido sobre riesgos y uso de IA según la función. |
A quién va dirigido
Para equipos que quieren ver qué ha cambiado y no quedarse en haber asistido
Encaja especialmente con
- Responsables de arquitectura de seguridad, AppSec y Platform Engineering que necesitan enseñar resultados a dirección.
- Empresas con PCI DSS, ISO 27001, SOC 2 o DORA donde la formación ya hay que documentarla.
- Engineering managers que ven código generado en producción y quieren saber en qué punto está su equipo.
- Equipos que usan Claude Code o GitHub Copilot y deciden los permisos caso por caso.
No es la formación adecuada si
- La empresa busca una charla de inspiración para todo el departamento.
- El objetivo es formar a doscientas personas. Para eso, una plataforma de formación sale más barata.
- El equipo aún no ha usado un asistente sobre un repositorio real.
- Lo que hace falta es una auditoría del código con informe de vulnerabilidades, o un certificado de cumplimiento de una norma.
Quién lo imparte
Seguridad y desarrollo contados por alguien que ha trabajado en los dos lados
Soy Daniel Alfocea y llevo veinte años en desarrollo y seguridad. En Banco Santander fui Principal Engineer del departamento de IA cuando se puso en marcha el área. En BBVA fui Tech Lead de ciberseguridad. En 42Crunch, en Reino Unido, fui responsable de uno de sus productos de seguridad de APIs.
He presentado investigación en RSA Conference y en OWASP AppSec EU, y he sido ponente habitual de RootedCON. El Instituto Nacional de Ciberseguridad (INCIBE) me ha llamado varias veces como juez de sus concursos. Fundé Navaja Negra y el capítulo de OWASP Madrid. Soy autor de herramientas de seguridad muy usadas, como GoLismero, Plecost y Dockerscan, y de LAPIS, una investigación publicada en arXiv sobre cómo describirle una API a un modelo con menos tokens. Con Alfonso Muñoz escribí MCP Seguro. Guía práctica para desarrolladores, arquitectos software y tech leads.
Este programa lo hago yo de principio a fin, del diagnóstico a la revisión de la semana 6. Los pull requests también los reviso yo y no se los paso a nadie.
Garantías
Lo que garantizo, por escrito
Si las configuraciones no funcionan, las arreglo
Si las configuraciones que dejo en el repositorio de la empresa no funcionan, hago una sesión remota gratuita para corregirlas.
Una hora más si a los 30 días el equipo sigue atascado
Si a los 30 días el equipo se ha atascado aplicando algo del programa, le dedico una hora en remoto, gratis.
Esto no es una auditoría y no prometo porcentajes, ni menos vulnerabilidades ni más productividad. Lo que dejo medido es el antes y el después del equipo.
Formato
Un equipo, seis semanas y una propuesta cerrada
El precio depende de la duración y del tamaño del equipo, y lo cerramos tras una llamada, según el stack, el número de repositorios y los indicadores que elija la empresa. Incluye el diagnóstico, el workshop, el paquete de evidencia, el informe, el seguimiento y la segunda medición.
- Participantes del mismo equipo o de áreas que trabajan juntas.
- Diagnóstico, workshop, paquete de evidencia, informe, seguimiento y revisión final.
- En español o en inglés.
- Sala, pantalla y wifi a cargo de la empresa el día del workshop. El resto es en remoto.
- Desplazamiento fuera de Madrid acordado antes de cerrar la fecha.
Antes de hablar