diff --git a/documentos/proyecto/5.Docker.md b/documentos/proyecto/5.Docker.md
index f341a8cb..7f8160e0 100644
--- a/documentos/proyecto/5.Docker.md
+++ b/documentos/proyecto/5.Docker.md
@@ -104,6 +104,19 @@ puede optar o no, por tanto, por usarlo, pero lo que hay que tener en cuenta es
 que las bibliotecas estarán *dentro* del contenedor, y los fuentes *fuera* del
 mismo, en un directorio donde *no hay derechos de escritura*.
 
+**Aviso**: este es un caso en el que las IAs generativas pueden
+generar automáticamente el Dockerfile completo, *y sistemáticamente lo
+hacen mal*, sin seguir las buenas prácticas habituales, con versiones
+aleatorias o deprecadas y en general en disonancia con lo que se pide
+en la ingeniería de software. Aunque la asignatura está diseñada para
+que si se envía algo que no cumpla todas las condiciones se explique
+al estudiante qué problemas hay a través del PR, se ahorrará bastante
+trabajo tanto al estudiante como a los otros estudiantes que revisen
+el PR como al profesor si se hace *a mano* siguiendo el manual o algún
+tutorial, entendiéndose así mejor las diferentes partes del Dockerfile
+y por supuesto la retroalimentación en el PR y cómo construir otros
+más complejos.
+
 ## Lista de comprobación
 
 Recuerda que hay que copiar y pegar en el PR de tu repositorio, y marcar lo que
diff --git a/documentos/proyecto/6.CI.md b/documentos/proyecto/6.CI.md
index 3fe9f347..a14f1271 100644
--- a/documentos/proyecto/6.CI.md
+++ b/documentos/proyecto/6.CI.md
@@ -54,8 +54,19 @@ Preparar un proyecto para integración continua implica varias cosas:
   API*](https://docs.github.com/en/rest/reference/checks).
 
 Esta fase de integración continua es esencial para el posterior
-despliegue en un PaaS o IaaS sobre el que se probarán técnicas de despliegue
-continuo.
+despliegue en la nube sobre el que se probarán técnicas de despliegue
+continuo (será el último objetivo de la asignatura).
+
+**Aviso**: este es un caso en el que tanto el mismo GitHub como
+CoPilot pueden generar automáticamente el fichero de workflow
+completo, *y sistemáticamente lo hacen mal*. Aunque la asignatura está
+diseñada para que si se envía algo que no cumpla todas las condiciones
+se explique al estudiante qué problemas hay a través del PR, se
+ahorrará bastante trabajo tanto al estudiante como a los otros
+estudiantes que revisen el PR como al profesor si se hace *a mano*
+siguiendo el manual o algún tutorial, entendiéndose así mejor las
+diferentes partes del *workflow* y por supuesto la retroalimentación
+en el PR y cómo construir otros más complejos.
 
 ## Lista de comprobación