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 vuestras configuraciones, el workshop completo, un informe para dirección con cinco acciones priorizadas y una segunda medición con vuestros propios números. No te voy a prometer un porcentaje de mejora. Lo que cambia, 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 que ya tenéis
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 os 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 decidisteis ayer caduca.
Hay un segundo problema: sentir que vas más rápido no es medir. 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 aquí se mide al principio y al final, y no os cuento cómo debería 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 tenéis cambios en el repositorio, un informe que enseñar a dirección y dos mediciones para compararlas.
Qué cambia al terminar
Cinco resultados que le podéis 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 lo dicen vuestros datos.
- 01
Saber desde qué punto partís
Con una encuesta de diez minutos al equipo y la revisión de las configuraciones de IA que ya tenéis 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 vuestro código. Las configuraciones quedan en una rama de vuestro 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 os apliquen, 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 vuestras 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 vuestros números.
Las fases
Qué pasa cada semana y quién lo hace
Casi todo el trabajo lo hago sin que el equipo tenga que parar. Os 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 tenéis en los repositorios y acordamos entre cuatro y seis indicadores. Con eso adapto los laboratorios a vuestro stack.
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 vuestro repositorio. 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 vuestro Slack o Teams y respondo en dos días laborables. El equipo me manda dos o tres pull requests reales y los comento por escrito, en vuestra plataforma y con vuestros permisos, o con fragmentos si preferís. 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 vuestro equipo, pero enseña que la impresión no vale como medida. Por eso no os voy a prometer un porcentaje. Elegimos juntos los indicadores que os sirvan a vosotros, 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 vuestras herramientas, 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 vuestro sistema de control de versiones.
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
| Si necesitáis | 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 vuestro código. | 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 decidís vosotros. | 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 os hace falta. Si se atasca, la garantía de los 30 días cubre una hora. | No hace falta. |
Lo que se queda en la empresa
Seis semanas después, esto es lo que os queda
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 vuestras 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 vuestros, 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. Si tenéis que explicar qué recibís, empezad por esta lista.
- +1
Paquete de evidencia de cumplimiento
Asistencia firmada, certificado individual con fecha, horas y contenidos, temario mapeado a las normas que os apliquen y carta de una página para el auditor.
- +2
Encuesta previa de diez minutos al equipo
Me sirve para adaptar los laboratorios a vuestro stack y es la base de la medición inicial.
- +3
Configuraciones en una rama de vuestro repositorio
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 vuestro equipo legal.
- +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 vosotros. El control lo ejecuta y lo mantiene la empresa, y aquí se documenta la formación. Cuando hablemos os digo cuáles aplican en vuestro caso.
| Norma | Qué pide | Qué os 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 vuestro expediente. |
| 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
- Buscáis una charla de inspiración para todo el departamento.
- Queréis formar a doscientas personas. Una plataforma de formación os saldrá más barata.
- El equipo aún no ha usado un asistente sobre un repositorio real.
- Esperáis una auditoría de vuestro código con informe de vulnerabilidades, o que certifique que cumplís 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 vuestro repositorio no funcionan, hago una sesión remota gratuita para corregirlas.
Si a los 30 días seguís atascados, una hora más
Si a los 30 días el equipo se ha atascado aplicando algo del programa, os dedico una hora en remoto, gratis.
Esto no es una auditoría y no os prometo porcentajes, ni menos vulnerabilidades ni más productividad. Lo que os dejo medido es vuestro antes y vuestro después.
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 elijáis. 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