Documentación, migraciones y revisión de seguridad

Qué aprenderás

• Ajustar una tarea documental a su audiencia y uso.
• Acotar migraciones con origen, destino y compatibilidad.
• Solicitar una revisión defensiva sin delegar toda la seguridad al modelo.

Documentación para una audiencia real

Indicá quién leerá el documento, para qué lo necesita, qué profundidad y formato convienen, qué ejemplos incluir y qué términos definir. Adjuntá la fuente autorizada, si el texto describe un producto o proceso. Pedí separar hechos, recomendaciones e información ausente; verificá luego citas, versiones y cobertura contra la fuente original.

Objetivo: preparar una guía de resolución para soporte de primer nivel.
Audiencia: conoce el producto, no programa.
Entrada: [procedimiento vigente y versión]
Salida: pasos numerados, señales de éxito y cuándo escalar.
Restricciones: no inventar opciones ni cambiar el sentido de la política.
Criterio: cada paso se puede comprobar con la fuente adjunta.

Migraciones: declarar punto de partida y destino

Una solicitud de migración debe nombrar origen y destino con versiones, alcance, restricciones, compatibilidad, comportamiento que se preserva, estrategia incremental y pruebas. Evitá «convertí todo este sistema» sin límites. Separá inventario, piloto, cambios por componente, validación y despliegue; identificá dependencias que todavía no se pueden migrar.

Objetivo: proponer una migración gradual del módulo de facturación.
Origen: VB6 + ADO 2.8, Windows Server [versión].
Destino: C# / .NET Framework 4.7, hospedado en IIS.
Preservar: cálculo de impuestos, formatos y contratos de archivo.
Restricciones: convivencia de ambos módulos durante el piloto; sin cambio de base.
Salida: inventario de riesgos, etapas, pruebas de equivalencia y rollback.

Revisión defensiva de seguridad

Pedí revisar aspectos concretos: validación, autenticación, autorización, secretos, inyección, exposición de datos, dependencias y logging. Aportá código relevante anonimizado, arquitectura y límites del análisis. Solicitá hallazgo, evidencia, impacto, escenario, recomendación y cómo probar; pedí que marque lo que no pudo verificar.

No incluyas credenciales, claves, datos personales ni material confidencial en un servicio sin autorización y controles adecuados. Una respuesta de IA es una ayuda para orientar revisión, no una certificación.

Una revisión de IA no sustituye auditorías, pruebas ni revisión especializada.

Un prompt puede ordenar el análisis; no concede permisos para inspeccionar el sistema, no ejecuta automáticamente pruebas y no garantiza descubrir vulnerabilidades. Validá en un entorno autorizado con herramientas y profesionales correspondientes.

Ejercicio

Escribí una solicitud para documentar una migración que requiera conservar facturación. Incluí dos versiones, la audiencia, una prueba de equivalencia y un caso que requiera rollback. ¿Qué evidencia pedirías antes de aprobar cada etapa?

Autoevaluación

¿Qué debe distinguir una revisión de seguridad asistida por IA? Evidencia observada, riesgo potencial, recomendación y aspectos no revisados. Su resultado orienta trabajo y debe validarse con pruebas y revisión especializada.

Fuentes

• NIST, AI Risk Management Framework: Generative AI Profile — riesgos y gestión de IA generativa; consulta: 2026-10-03.
• OWASP GenAI Security Project, LLM Top 10 — riesgos de aplicaciones con modelos; consulta: 2026-10-03.
• SitioDeRubros, Testing, seguridad y privacidad del código — referencia de verificación de código; consulta: 2026-10-03.
• OpenAI, Prompt engineering — formulación y estructura de solicitudes; consulta: 2026-10-03.

Seguir aprendiendo

• Unidad 15: convertir instrucciones probadas en una plantilla mantenible.
• Módulo 5: uso profesional, responsable y seguro de IA.