0% del curso completado
Prompts para operaciones de red: clasificación de datos, formato, persona e instrucciones (5.2)
📋 En esta lección
El examen plantea este tema como una elección: ante una tarea de operación de red, seleccionar el prompt adecuado valorando sus componentes — y muy especialmente qué datos puedes pegar y cuáles no. Aquí tienes los cinco componentes de un prompt profesional, la regla de clasificación de datos que evita el incidente de seguridad, y ejemplos aplicados a las tareas reales del oficio.
Por qué esto es materia de examen
Un prompt es una instrucción a un sistema que no conoce tu red. La diferencia entre "explícame este error" y una petición bien construida es la diferencia entre una respuesta genérica de manual y un análisis aplicable a tu caso. Y en un contexto profesional hay una segunda dimensión que el blueprint destaca: lo que escribes en el prompt sale de tu organización. Ambas cosas — eficacia y prudencia — se evalúan.
Los cinco componentes
1. Persona — quién debe responder
Fijar el rol del sistema orienta vocabulario, profundidad y prioridades.
"Actúa como ingeniero de redes sénior especializado en switching Cisco IOS."
Sin persona, la respuesta apunta a un público indefinido: puede explicarte qué es una VLAN cuando lo que necesitabas era el matiz de una configuración. Con persona, el registro es el de un colega del oficio.
2. Instrucción — qué quieres exactamente
El verbo importa: analiza, compara, resume, genera, explica, verifica. Y lo que delimita la tarea: alcance, restricciones y qué no quieres.
"Analiza esta salida e identifica la causa más probable del problema. No propongas cambios de configuración todavía."
3. Contexto — lo que el sistema no puede saber
Topología relevante, qué cambió recientemente, qué ya has descartado, síntomas y alcance. Es lo que convierte una respuesta de libro en una hipótesis sobre tu red.
"Switch de acceso Catalyst con Rapid PVST+. El usuario del puerto Fa0/7 perdió conectividad esta mañana; el resto de la planta funciona. Ayer se recablearon varios puestos."
4. Formato de salida — cómo quieres la respuesta
Un componente que el blueprint nombra expresamente, porque decide si la respuesta es utilizable:
"Devuelve una tabla con tres columnas: síntoma, causa probable y comando de verificación." "Responde en JSON con las claves
causa,evidenciaysiguiente_paso." "Máximo cinco líneas, sin introducción."
Pedir JSON cuando la respuesta va a alimentar un script (11.3), una tabla cuando vas a comparar opciones, una lista de comandos cuando vas a ejecutarlos paso a paso.
5. Clasificación de datos — qué puedes pegar
El componente que distingue un uso profesional de uno imprudente, y el que más peso tiene en la formulación del tema.
⚠️ ⚠️ Lo que escribes en un prompt sale de tu organización
Antes de pegar nada, pregúntate qué clase de dato es. Según el servicio y su contrato, lo enviado puede almacenarse, procesarse fuera de tu jurisdicción o revisarse por terceros. Trátalo como lo que es: información que abandona tu perímetro.
Nunca se pega:
- Credenciales de cualquier tipo: contraseñas, hashes de
enable secret, claves precompartidas de VPN, community strings SNMP, tokens y claves de API (11.3). - Datos personales de usuarios o clientes (nombres, correos, identificadores) — con las obligaciones legales que eso conlleva.
- Direccionamiento público y topología completa de la organización: un mapa de red real es inteligencia de reconocimiento servida (10.1).
Se sanea antes de pegar:
- Sustituye IPs públicas por los rangos de documentación (
203.0.113.x— 4-2) y mantén las privadas solo si no revelan un diseño sensible. - Reemplaza hostnames corporativos por genéricos (
SW-ACCESO-01). - Recorta la salida a las líneas que importan — además de reducir exposición, mejora la respuesta: menos ruido, más foco.
Se puede compartir con normalidad: salidas sanitizadas, mensajes de error genéricos, dudas conceptuales, configuraciones de ejemplo sin secretos.
Y la regla de oro organizativa: usa las herramientas aprobadas por tu empresa. Muchas organizaciones ofrecen instancias corporativas con garantías contractuales de no retención; pegar en un servicio personal lo que no debería salir es un incidente de seguridad aunque la intención fuera buena.
Un prompt completo, componente a componente
La misma consulta, mal y bien:
Prompt pobre:
"¿Por qué no funciona este puerto?"
[pegado de 400 líneas de show running-config completo, con enable secret y SNMP community incluidos]
Problemas: sin persona ni formato, sin contexto de qué falla exactamente, y fuga de credenciales en la configuración pegada.
Prompt profesional:
Actúa como ingeniero de redes sénior especializado en Cisco IOS. (persona)
Contexto: switch de acceso con Rapid PVST+, PortFast y BPDU guard en los puertos de usuario. El puesto del puerto Fa0/7 perdió conectividad esta mañana; el resto de la planta funciona con normalidad. Ayer se recablearon varios puestos. (contexto)
Analiza esta salida e identifica la causa más probable, indicando en qué evidencia concreta te basas. (instrucción)
FastEthernet0/7 is down, line protocol is down (err-disabled) %PM-4-ERR_DISABLE: bpduguard error detected on Fa0/7, putting Fa0/7 in err-disable state(datos: solo las líneas relevantes, sin credenciales ni identificadores corporativos)
Devuelve: (1) causa más probable, (2) evidencia que la sostiene, (3) comandos de verificación, (4) pasos de corrección. Máximo diez líneas. (formato)
Los cinco componentes están presentes y el dato pegado es exactamente el necesario. Fíjate en algo: este prompt solo lo escribe quien entiende el problema — saber qué líneas son las relevantes ya es conocimiento de red.
Cuatro usos que rinden de verdad
| Tarea | Qué pedir | Qué verificar después |
|---|---|---|
| Interpretar salidas | Análisis de contadores o logs sanitizados, con la evidencia citada | Que la evidencia esté realmente en la salida |
| Generar configuración | Comandos IOS para un objetivo concreto, con la sintaxis de tu plataforma | Cada línea, antes de aplicar: sintaxis, efecto y efectos colaterales |
| Explicar conceptos | Aclaraciones, analogías, comparaciones entre protocolos | Contrastar con documentación oficial de Cisco |
| Redactar | Postmortems, documentación de cambios, resúmenes para dirección | Los datos y las conclusiones técnicas |
⚡ La verificación no es opcional en ninguno de los cuatro
Un prompt bien construido mejora la probabilidad de una buena respuesta; no garantiza que sea correcta. Los sistemas generativos producen configuración plausible con comandos que no existen en tu versión de IOS, o sintaxis de otro fabricante con aspecto convincente. Contrastar contra la documentación oficial y probar en laboratorio antes de producción es parte del procedimiento, no una precaución opcional — la misma exigencia de evaluación que la lección 11.7 aplicaba a los agentes.
Anti-patrones frecuentes
- Pegar la configuración completa "por si acaso": maximiza la exposición y diluye la atención del modelo. Recorta.
- Preguntas sin contexto ("¿por qué falla OSPF?"): devuelven el índice de un manual.
- Aceptar la primera respuesta sin iterar: si la respuesta no encaja, refina — añade el dato que faltaba, acota el alcance, corrige el malentendido. La conversación es la herramienta.
- Pedir que decida por ti ("¿qué hago?") en lugar de pedir análisis y opciones con sus implicaciones: la decisión — y la responsabilidad — son tuyas.
- Usar la herramienta personal para datos corporativos: el incidente de seguridad más fácil de cometer sin mala intención.
Relación con otros conceptos
- La prudencia con credenciales es la misma de los tokens de API (11.3) y de Ansible Vault (11.4); la clasificación de datos y el reconocimiento como amenaza, la 10.1.
- Los rangos de documentación para sanear direcciones vienen de la 4.2; las salidas que interpretarás, de los Módulos 2 a 10.
- La exigencia de verificar antes de aplicar es la misma que la evaluación de agentes de la 11.7.
- Escribir buenos prompts exige entender el problema: es el Módulo 12 (metodología) el que te da qué preguntar.
Resumen
Un prompt profesional para operación de red combina cinco componentes: persona (el rol que responde), instrucción (verbo y alcance precisos), contexto (topología, cambios recientes, qué ya descartaste), formato de salida (tabla, JSON para scripts, número máximo de líneas) y clasificación de datos — el que más pesa en el tema 5.2: nunca credenciales (contraseñas, hashes, PSK, communities, tokens), datos personales ni topología y direccionamiento público reales; sanea sustituyendo IPs por rangos de documentación y hostnames por genéricos, y pega solo las líneas relevantes; usa las herramientas aprobadas por tu organización. Usos que rinden: interpretar salidas, generar configuración, explicar conceptos y redactar documentación — los cuatro con verificación obligatoria contra documentación oficial y laboratorio, porque un buen prompt mejora la probabilidad de acierto pero no la garantiza. Y la observación de fondo: escribir el prompt correcto ya requiere saber de redes.