Cómo aprendimos a escribir mejores prompts en Gemini para personal de salud

Fui instructor de un curso para personal de salud en el que mostraba nuevas tecnologías y cómo estas podían ayudarnos en el trabajo diario. En ese grupo, muchos ya utilizaban herramientas de Google en su práctica cotidiana. Por eso, en una de las clases, el paso natural fue trabajar con Gemini.

No queríamos quedarnos en la curiosidad de “preguntarle cosas a la IA”. Lo que necesitábamos era algo más útil: aprender a darle instrucciones de una forma que realmente sirviera en contextos clínicos, educativos y de revisión de información. De esa sesión salió la guía que habíamos preparado para la clase, y este post recoge esa experiencia en una versión más narrativa y práctica.

La idea de fondo era simple. La inteligencia artificial puede ayudar bastante, pero no porque “sepa mucho” de forma mágica, sino porque responde mejor cuando uno sabe pedir mejor. En salud eso importa todavía más. Un prompt mal planteado no solo produce una respuesta pobre: también puede generar confusión, exceso de confianza o una salida difícil de verificar.

Antes de todo: una regla que no se negocia

La primera parte de la clase no fue técnica. Fue una advertencia.

Cuando trabajamos con herramientas generativas en salud, hay un límite que no se debe cruzar: no introducir datos reales de pacientes ni información que permita identificarlos. Nada de nombres, historias clínicas, números de documento, fechas exactas o cualquier dato sensible que entre en la categoría de información protegida.

La IA puede apoyar, resumir, organizar y hasta ayudar a pensar. Pero no reemplaza el juicio clínico ni las validaciones humanas. Y menos aún justifica descuidos con la confidencialidad.

Por eso, en toda la guía, los ejemplos se plantean con casos hipotéticos y anonimizados. Esa decisión no es un detalle metodológico. Es parte del uso responsable de la herramienta.

El problema real no era Gemini: era cómo dar la instrucción

Lo que veíamos en clase era bastante claro. Muchas personas hacían preguntas demasiado generales:

• “Explícame la diabetes”.
• “Hazme un plan de cuidados”.
• “Resume esta guía clínica”.

Gemini respondía, sí, pero las respuestas solían salir demasiado amplias, ambiguas o poco ajustadas al contexto. Entonces la clase cambió de foco. En lugar de preguntar “qué puede hacer Gemini”, empezamos a preguntarnos “cómo deberíamos hablarle para que sea útil en nuestro trabajo”.

Ahí nació el método central de la guía: una adaptación clínica del formato SOAP.

El método SOAP, pero convertido en una estructura para prompts

Tomamos el SOAP, tan conocido en el entorno sanitario, y lo usamos como una plantilla mental para construir mejores solicitudes.

• S - Sujeto y Rol: desde qué perspectiva debe responder la IA.
• O - Objetivo y Contexto: para qué sirve la solicitud y en qué situación se usará.
• A - Acción: qué tarea concreta debe realizar.
• P - Plan: en qué formato debe entregar la respuesta.

La ventaja del método era inmediata. Dejaba de ser una conversación vaga con una herramienta y se convertía en una instrucción profesional, con contexto, propósito y forma de salida.

Un ejemplo sencillo sería algo así:

S: Actúa como un farmacólogo clínico.
O: Estoy preparando un resumen para una sesión clínica sobre interacciones medicamentosas.
A: Compara los mecanismos de acción y efectos adversos del clopidogrel y el ticagrelor.
P: Preséntalo en una tabla con tres columnas.

Eso, que parece simple, cambia bastante el resultado. La IA ya no tiene que adivinar el tono, la audiencia ni el formato. Uno se lo dice desde el inicio.

Cuando la tarea crece, también tiene que crecer la estructura

Otra idea importante de la clase fue que no todos los prompts necesitan el mismo nivel de detalle. Para una tarea rápida puede bastar una instrucción breve. Pero cuando el problema se vuelve más complejo, conviene estructurarlo visualmente.

En la guía propusimos dos formatos principales.

Primer formato: Markdown para la mayoría de casos

El formato más práctico para trabajar día a día fue Markdown. Es fácil de leer, fácil de corregir y bastante natural para casi cualquier usuario. Basta con dividir el prompt en secciones como Rol, Contexto, Tarea y Formato de salida.

Por ejemplo:

### Rol ###
Actúa como un educador en diabetes para enfermería.

### Contexto ###
Necesito crear un folleto simple para un paciente recién diagnosticado con Diabetes Mellitus tipo 2, de 70 años y con baja afinidad por la tecnología.

### Tarea ###
Redacta un texto que explique:
1. Qué es la diabetes tipo 2.
2. La importancia de medir el azúcar en sangre.
3. Tres cambios clave en la alimentación.
4. Dos beneficios de caminar 20 minutos al día.

### Formato de salida ###
- Tono empático y claro.
- Párrafos cortos y viñetas.
- Evita jerga médica.

Este formato funcionaba muy bien para materiales educativos, resúmenes de clase, explicaciones para pacientes y borradores de documentos de apoyo.

Segundo formato: XML cuando se necesita máxima precisión

Cuando el caso tenía varias capas, varios datos clínicos y varias instrucciones encadenadas, el formato que mejor funcionaba era uno con etiquetas tipo XML. No porque fuera elegante, sino porque obligaba a separar bien los componentes.

Eso servía mucho en tareas como diagnóstico diferencial, comparación de criterios o evaluación de elegibilidad para ensayos clínicos. En vez de meter todo en un párrafo largo, se podía organizar por bloques: <rol>, <caso_hipotetico>, <laboratorio>, <instrucciones>.

Un ejemplo breve sería:

<prompt_clinico>
  <rol>
    Actúa como un médico internista experto en diagnóstico diferencial.
  </rol>
  <caso_hipotetico>
    <paciente>Varón de 55 años.</paciente>
    <sintomas>Fatiga progresiva, poliuria y polidipsia.</sintomas>
    <laboratorio>
      <glucosa_ayunas>250 mg/dL</glucosa_ayunas>
      <HbA1c>9.5%</HbA1c>
    </laboratorio>
  </caso_hipotetico>
  <instrucciones>
    <paso_1>Genera 3 diagnósticos diferenciales.</paso_1>
    <paso_2>Justifica cada uno en una frase.</paso_2>
    <paso_3>Ordénalos del más al menos probable.</paso_3>
  </instrucciones>
</prompt_clinico>

En clase esta diferencia se entendió rápido: Markdown era el formato cómodo para el trabajo general; XML era el formato útil cuando el caso requería más disciplina y precisión.

Los casos de uso que más sentido tuvieron

Una de las cosas más valiosas de esa sesión fue que dejamos de hablar de prompts “en abstracto” y empezamos a aterrizarlos en tareas muy concretas del personal de salud.

1. Educación al paciente

Aquí Gemini resultaba especialmente útil cuando se definía bien el tono y el nivel de lenguaje. No era lo mismo pedir una explicación general que pedir una explicación para los padres de un niño, para un adulto mayor o para alguien con baja alfabetización digital.

Por ejemplo:

Actúa como un cardiólogo pediátrico. Explícale a los padres de un niño de 8 años qué es una comunicación interauricular usando una analogía simple y un tono tranquilizador.

Ese tipo de prompt producía respuestas mucho más humanas y utilizables que una simple definición enciclopédica.

2. Revisión de literatura científica

Otra tarea muy útil era tomar un abstract y pedir algo concreto: extraer la metodología, resumir limitaciones, identificar la pregunta PICO o aislar hallazgos clave.

Por ejemplo:

Te comparto el abstract de un ensayo clínico. Resume los hallazgos principales en 3 viñetas y extrae el número de participantes y la duración del estudio.

La clave era esa: pedir tareas específicas. No “resume esto” a secas, sino “extrae esto, organiza esto otro y presenta el resultado así”.

3. Planificación de cuidados en enfermería

Este fue uno de los puntos donde la estructura realmente brilló. Cuando se describía bien un escenario clínico, Gemini podía ayudar a generar un borrador útil para pensar diagnósticos NANDA, intervenciones NIC o resultados esperados.

No como producto final, por supuesto, sino como apoyo para ordenar ideas.

Genera un borrador de un plan de cuidados de enfermería para un paciente hipotético de 80 años, hospitalizado por neumonía, con riesgo de caídas y deterioro de la deglución. Incluye 2 diagnósticos NANDA prioritarios con sus intervenciones NIC.

4. Comparación de guías o fármacos

En contextos de actualización clínica, la instrucción más útil era casi siempre la misma: comparar en tabla.

Crea una tabla que compare las guías AHA/ACC 2022 y ESC 2023 sobre hipertensión arterial, enfocándote en los umbrales de tratamiento para pacientes de bajo riesgo.

Ese tipo de salida permite revisar diferencias sin perderse en un bloque largo de texto.

5. Pedir razonamiento paso a paso

Una técnica que funcionó bien en clase fue añadir una instrucción explícita del tipo: “Razona tu respuesta paso a paso”. Esto no reemplaza la revisión crítica, pero ayuda a ver la lógica que el modelo está siguiendo.

Paciente hipotético presenta hiponatremia con osmolaridad sérica baja y osmolaridad urinaria alta. Razona paso a paso para llegar al diagnóstico diferencial de SIADH.

En tareas fisiopatológicas o de diagnóstico diferencial, esa simple frase hacía una gran diferencia.

Cuando los escenarios se vuelven complejos

La guía también incluía ejercicios más avanzados, porque queríamos mostrar que Gemini no solo servía para preguntas sueltas. También podía apoyar en tareas multifacéticas si el prompt estaba bien construido.

Dos ejemplos destacaban bastante.

El primero era un plan de alta para un paciente complejo, donde se combinaban resumen clínico, educación al paciente, medicación, signos de alarma y próximos pasos. Ahí el formato Markdown funcionaba bien porque el producto final era un documento legible.

El segundo era una pre-evaluación para un ensayo clínico, donde había que comparar criterios de inclusión y exclusión contra un perfil clínico. En ese caso, XML resultaba mucho más claro porque la tarea requería precisión al contrastar condiciones.

Lo importante no era memorizar esos ejemplos, sino entender el principio: cuanto más compleja sea la tarea, más importante es separar los datos, las instrucciones y el formato esperado.

La lección más importante de la clase

Si tuviera que resumir toda la sesión en una sola idea, sería esta: trabajar bien con Gemini no consiste en hacer preguntas más largas, sino en hacer instrucciones más claras.

Eso implica cuatro cosas muy concretas:

• definir el rol que debe asumir la IA;
• explicar para qué sirve la respuesta;
• pedir una tarea precisa;
• y decir en qué formato debe entregarla.

En salud, esa claridad no solo ahorra tiempo. También reduce ambigüedad, mejora la utilidad del resultado y hace más fácil revisar críticamente la respuesta.

Un buen prompt no reemplaza el criterio clínico

La guía que usamos en esa clase no buscaba convertir a Gemini en una autoridad clínica. Buscaba algo más razonable: usarlo como un asistente mejor dirigido.

Ese matiz importa. La IA puede ayudar a redactar materiales, resumir artículos, comparar información o estructurar ideas. Pero la responsabilidad final sigue siendo humana. Siempre.

Por eso, la mejor forma de usar estas herramientas en salud no es tratar de delegarlo todo, sino aprender a conversar con ellas con método, contexto y prudencia.

Y justamente de eso trató esa clase: de pasar del entusiasmo general por la tecnología a algo mucho más útil, que es saber integrarla con sentido en el trabajo diario.