Alcance de este artículo (léase primero) Este artículo trata sobre la configuración de hacer leer a un LLM multimodal de propósito general (ChatGPT/Claude, etc.) PDFs e imágenes de mapas meteorológicos dibujados para humanos. Esto es técnicamente distinto de los modelos de predicción numérica por IA especializados, como GraphCast o AIFS. Estos últimos no leen en absoluto la "imagen" de un mapa meteorológico: trabajan directamente con tensores numéricos como ERA5, aprenden física y han llegado a superar a los métodos convencionales en la predicción de trayectorias de tifones. Las "limitaciones" de este artículo son propias del primero (LLMs que leen imágenes) y no son las limitaciones de la IA meteorológica en general. Esta distinción es el núcleo de esta serie. En la continuación (Parte 4) se abordará la forma de conectar el "copiloto" que aquí diseñamos, no con "imágenes de mapas meteorológicos", sino con "salidas estructuradas de predicción numérica por IA". Este artículo es el paso previo: diseñar un reparto de roles que aporte valor incluso bajo la premisa de "hacer leer imágenes".

Punto de partida: la decisión de "no cerrar el ciclo"

Lo que quedó claro hasta la Parte 2 es que las limitaciones estructurales que tiene la IA generativa actual en el análisis de mapas meteorológicos (dibujados) no pueden superarse solo con ajustes de prompt.

A partir de aquí hay dos opciones posibles.

  1. No usar IA — Es lo más seguro, pero se renuncia al valor exclusivo de la IA (explicaciones en lenguaje natural, 24 horas al día, para múltiples ubicaciones).
  2. Cambiar a un diseño que no haga que la IA "actúe como un meteorólogo perfecto" — Asumir las limitaciones como punto de partida y generar valor mediante el reparto de roles con humanos.

En este artículo seguimos la opción 2 y pensamos el diseño para integrar la IA en un servicio real (imaginemos una "aplicación de explicación meteorológica").

Filosofía de diseño: la IA como "navegante" y el humano como "piloto" — pero ¿quién es el comandante?

En lugar de delegar completamente el análisis de mapas meteorológicos a la IA, redefinimos la relación así:

  • IA: extrae datos y genera una guía sobre "qué hay que observar".
  • Humano: toma la decisión final.

La imagen es la de un copiloto en una aeronave. Las decisiones de vuelo importantes las toma el comandante (humano), mientras el copiloto (IA) lee los instrumentos y los procedimientos que deben verificarse.

La primera versión de este artículo decía que "aunque la IA malinterprete algo, no será un error fatal porque el usuario finalmente mira el mapa meteorológico para confirmarlo". La versión revisada corrige de frente esa premisa.

Corrección: la metáfora del copiloto tiene un agujero que la primera versión pasó por alto. El copiloto puede ser de confianza cuando lee en voz alta porque el comandante es un experto capaz de detectar errores. Sin embargo, los usuarios previstos de este servicio son montañeros y ciudadanos con fines de protección civil, no especialistas en meteorología. El Dr. Tsuyoshi Sekiyama, del Instituto Meteorológico de Japón, ha afirmado explícitamente que "las alucinaciones ocurren inevitablemente. Un profano no puede detectarlas. Solo un especialista entrenado puede percibir que algo no encaja". Es decir, mientras se coloque a un usuario general en el rol de "comandante", no habrá nadie a bordo capaz de detectar las mentiras del copiloto (IA).

Por lo tanto, un diseño que haga depender la red de seguridad de "que el propio usuario mire el mapa y lo confirme" no es viable. La red de seguridad debe reubicarse en otro lugar.

Reubicación de la red de seguridad: no verificación visual, sino "derivación hacia textos oficiales confirmados"

Trasladamos el punto de referencia para la verificación final desde el juicio visual del usuario hacia una derivación clara hacia los comunicados oficiales y textos confirmados de la Agencia Meteorológica de Japón.

  • La explicación de la IA se limita a ser una "puerta de entrada para profundizar la comprensión" y una "guía visual sobre qué observar".
  • Las conclusiones relacionadas con la protección civil y las decisiones de actuación se garantizan no con la explicación de la IA, sino con un flujo que lleva al usuario a la información oficial confirmada de la Agencia Meteorológica (avisos, alertas, materiales de explicación de predicciones a corto plazo, predicciones por punto).
  • Se prepara una interfaz que permita acceder con un solo toque a la información oficial correspondiente desde cualquier punto de la explicación.

Seré honesto sobre este dilema. Decir que "la explicación en lenguaje natural de la IA tiene valor" y luego, en los momentos críticos, remitir al exterior con un "consulte los comunicados oficiales" es un acto que niega parcialmente el valor de la propia explicación de la IA. Es una tensión que no puede resolverse del todo. Este diseño la convierte en algo operativamente manejable separando intencionalmente "mejorar la comprensión e interés del usuario con la explicación" de "dejar las decisiones importantes a la información confirmada". No cargar sobre los ojos del usuario general la responsabilidad de la verificación final — este es el mayor cambio de política respecto a la primera versión.

Los tres roles que se delegan a la IA

Rol 1: guía de puntos de interés (orientación visual)

Cuando el usuario abre el visor de mapas meteorológicos, la IA explica los "puntos de atención del día".

Ejemplo: "El punto de atención de hoy es el FXJP854 a 850 hPa. Fíjese en cómo la línea de 306 K avanza hacia el norte desde el oeste de Kyushu. Esta será la fuente de energía de las lluvias intensas de mañana. Mueva el deslizador 24 horas hacia adelante y compruebe cómo penetra el aire cálido."

Siguiendo la guía de la IA y manipulando el mapa meteorológico, el usuario obtiene la experiencia de "descubrir" por sí mismo los cambios en los fenómenos meteorológicos. Lo que la IA proporciona aquí no es "la respuesta", sino "el punto de enfoque". El rol de la IA se confina intencionalmente en un ámbito donde, aunque se equivoque, no repercute directamente en las decisiones de actuación.

Rol 2: explicación del contexto físico

A partir de los datos extraídos, se complementa el contexto meteorológico de "por qué ocurre esto".

Ejemplo: "A 500 hPa (5500 m de altitud) está entrando aire frío de -30 °C, pero en superficie hay cielos despejados bajo un anticiclón. Esta 'diferencia de temperatura entre capas' provoca tormentas por la tarde (inestabilidad atmosférica). Las zonas que coinciden con el área de ascenso a 700 hPa requieren especial atención."

Esto tiene el potencial de ofrecer, para cada predicción diaria, el tipo de valor que encontraríamos en un libro de explicaciones de un meteorólogo veterano. Sin embargo, como se detalla más adelante, la condición es que los valores numéricos que sirven de base para esta explicación no se hagan leer a la IA desde la imagen, sino que se le proporcionen desde datos confirmados.

Rol 3: verificación cruzada con datos textuales externos

Si el análisis de imágenes es débil, se refuerza con datos textuales. Se obtienen por separado los datos numéricos de los "materiales de explicación de predicciones a corto plazo" de la Agencia Meteorológica y de las predicciones por punto, y se pasan a la IA como texto.

Esto permite hacer lo siguiente:

"Los materiales de explicación de la Agencia Meteorológica indican 'con el descenso de la JPCZ (Zona de Convergencia del Mar de Japón)…'. Si lo verificamos en el mapa de superficie FXFE502…"

Es decir, se puede contrastar el análisis de la imagen con información textual. Los hechos se obtienen del texto confirmado, y la imagen se usa como contexto auxiliar.

Consideraciones arquitectónicas: "los hechos provienen de datos estructurados"

Cuando se genera en lote la explicación meteorológica con una arquitectura serverless (AWS Lambda, etc.), los puntos clave del diseño son los siguientes.

No hacer que la IA lea datos numéricos

Los parámetros como temperatura, viento y presión por ciudad se extraen directamente de los OpenData (JSON/XML) y datos GPV de la Agencia Meteorológica y se pasan a la IA como entrada de texto en el prompt.

Como vimos en la Parte 2, el riesgo de errores de lectura al hacer que la IA lea valores numéricos desde imágenes es demasiado alto. De hecho, las limitaciones 1 y 2 de la Parte 2 (incompatibilidad de proyecciones cartográficas / imposibilidad de seguir isolíneas densas) se deben al diseño de entrada de hacer que una máquina lea una imagen dibujada para humanos. Si se proporcionan los valores directamente, estos problemas pueden evitarse en la fase de diseño.

Las imágenes se pasan solo como "contexto"

A la IA, una vez proporcionados los valores numéricos precisos extraídos como texto como premisa, se le indica:

"A partir de la configuración de presión que subyace a estos valores, léala a grandes rasgos en la imagen del mapa meteorológico adjunto y elabore un comentario sobre los puntos de interés para el usuario."

De este modo, el análisis de imágenes de la IA solo se encarga de "dar sabor al texto", y los errores graves dejan de propagarse a las conclusiones de la predicción.

Reparto de responsabilidades en tres niveles (revisado)

La tabla de reparto de responsabilidades de la primera versión tenía "verificación final = revisión visual del usuario". En la versión revisada se cambia el destinatario de la garantía de la verificación final.

Capa Responsable Contenido
Extracción de datos Sistema (Lambda) Obtención de datos textuales y numéricos confirmados desde OpenData/GPV de la Agencia Meteorológica
Interpretación y explicación IA (copiloto) Añade una narrativa meteorológica a los datos / se limita a la orientación visual y la explicación de contexto
Garantía física final Datos confirmados (numéricos) + especialistas humanos La corrección de los valores que sustentan la explicación la garantizan los datos confirmados; la responsabilidad final de la coherencia física recae en los especialistas
Confirmación de decisiones importantes Flujo hacia los comunicados oficiales de la Agencia Meteorológica Las decisiones de protección civil y actuación se confirman no con la vista del usuario, sino con información oficial confirmada

El punto clave es que la verificación final, que en la primera versión se concentraba en una sola fila de "humano (usuario)", se ha desglosado en tres elementos: "datos confirmados", "especialistas" y "flujo hacia los comunicados oficiales". Esto traslada al diseño arquitectónico el principio de no esperar que el ojo del usuario general haga las veces de especialista.

Prompt mejorado: detección de contradicciones, tipo cauteloso (con corrección de posicionamiento)

A continuación se muestra un extracto del diseño de prompt para operar la IA como "copiloto".

【Configuración del sistema】
Eres un "validador de datos cauteloso" con conocimientos de dinámica meteorológica.
Ten presente que los modelos de visión actuales de IA tienen limitaciones graves
en el reconocimiento de la distorsión espacial de la proyección polar estereográfica
y en el seguimiento de isolíneas densas.
Está estrictamente prohibido crear conjeturas o "escenarios de predicción verosímiles".

【Reglas de análisis: cumplir estrictamente las siguientes restricciones】
1. Declaración de ilegibilidad: si las líneas se cruzan o están densas y no puedes
   estar seguro, nunca hagas suposiciones; escribe "Ilegible (Unreadable)".
2. Prohibición de inferencia geográfica: no infiereas posiciones a partir de la
   curvatura de paralelos y meridianos; usa solo "coordenadas absolutas" como
   la línea de costa de las islas japonesas que puedas ver claramente.
3. Eliminación de exceso de confianza: evita expresiones categóricas
   ("será ~", "se prevé ~") y limítate a expresiones como
   "parece que ~" o "existe la posibilidad de ~".

【Pasos de ejecución】

■ Paso 1: Autoevaluación del nivel de confianza visual (metacognición)
Para cada figura adjunta, evalúa la "legibilidad de las líneas" en torno a las
islas japonesas y declara el resultado en 3 niveles: [Alto] / [Medio] / [Bajo].
Si es [Bajo], detén cualquier inferencia a partir de esa figura.

■ Paso 2: Extracción de datos locales (sin suposiciones)
Limitándote al área de las islas japonesas, extrae en forma de lista
solo los valores y elementos que puedas leer claramente en la figura.
Omite los elementos que no puedas leer.

■ Paso 3: "Detección de contradicciones" físicas y climatológicas (※ como verificación auxiliar)
Combina los datos extraídos y pásalos por un "filtro" para detectar
"puntos físicamente incorrectos" a la luz de la dinámica meteorológica
y la climatología de Japón.
Si detectas una contradicción, márcala con una bandera indicando
"alta probabilidad de error de lectura de imagen"
(no hagas una determinación definitiva).

■ Paso 4: Explicación meteorológica limitada tras eliminar contradicciones
Usa solo los datos que hayan superado el Paso 3 para elaborar
una explicación limitada.

El núcleo de este prompt son tres puntos: "no hacer que cree escenarios de predicción", "hacer que reconozca cuando no puede leer algo" y "pasar por un filtro las contradicciones físicas".

Corrección importante de posicionamiento: la detección de contradicciones físicas se degrada de "protagonista" a "auxiliar". La primera versión decía que la detección de contradicciones del Paso 3 sería "el protagonista". Sin embargo, dado que en la Parte 2, limitación 3, se concluyó que "los LLM no tienen un modelo físico y no comprenden la dinámica de fluidos", encargar a ese mismo LLM la detección de contradicciones físicas en un rol protagonista supone una tensión de principio. No se puede delegar la responsabilidad final del juicio de coherencia física a algo que no entiende la física. Por lo tanto, en la versión revisada, la detección de contradicciones se degrada al rol de "filtro primario auxiliar para descartar salidas claramente incorrectas". La garantía física final no recae en la autoverificación de la IA, sino en (1) la corrección de los propios datos confirmados (numéricos) y (2) el juicio de especialistas humanos. La detección de contradicciones mediante prompt se mantiene como un paso previo al control por especialistas para reducir los "accidentes evidentes", pero no se le otorga más confianza que esa.

Y aun así, las alucinaciones no desaparecen por completo. Es necesario reconocer que el prompt es solo un recurso para reducir la probabilidad, no un medio para superar las limitaciones en sí mismas.

Cómo gestionar los riesgos residuales: diseño de los avisos

Aunque se mejore el prompt, las alucinaciones persisten. Por ello, lo honesto es no ocultarlo desde el sistema y comunicárselo con transparencia al usuario.

Especialmente si se contemplan usuarios para quienes las decisiones meteorológicas pueden ser cuestión de vida o muerte, como montañeros, aviadores o personas en situaciones de emergencia, esto es un elemento de diseño imprescindible. Y como se ha señalado antes, ese usuario no es un especialista capaz de detectar mentiras — precisamente por eso, los avisos no deben decir "verifícalo tú mismo", sino orientar hacia "consulta la respuesta correcta externa que son los datos confirmados".

Patrón A: uso cotidiano (en línea)

Aviso ligero que se muestra permanentemente justo debajo del texto explicativo.

⚠️ Información de referencia generada por IA Esta explicación es el resultado de que una IA ha interpretado de forma autónoma las tendencias del mapa meteorológico. En el análisis de figuras complejas pueden incluirse errores de posición o valores numéricos (alucinaciones). Estos errores son difíciles de detectar sin conocimientos especializados. Para cualquier decisión meteorológica final o acción de protección civil, no confíe en su propia lectura: consulte siempre los comunicados oficiales de la Agencia Meteorológica.

Patrón B: incorporación inicial (términos de uso)

Gestión del riesgo de carácter más formal que se presenta al comenzar a usar el servicio.

Sobre la función de explicación de mapas meteorológicos por IA Esta función tiene como objetivo apoyar la interpretación de modelos meteorológicos y mapas de altura y profundizar en la comprensión de la meteorología. Dadas las características de la IA generativa, existe la posibilidad de que se genere información inexacta o contenido contradictorio en el reconocimiento espacial de imágenes (mapas meteorológicos) y en la extracción de valores numéricos. Estos errores se presentan en forma de texto natural y convincente, por lo que resulta difícil que personas sin conocimientos especializados los detecten. No utilice las explicaciones de esta IA como único fundamento para tomar decisiones importantes relacionadas con la vida o el patrimonio, como el montañismo, la navegación marítima, la aviación, la agricultura o la protección civil ante tifones o lluvias intensas. Para verificar la exactitud de la información, consulte siempre la información publicada por organismos oficiales como la Agencia Meteorológica de Japón.

Patrón C: exclusivo para situaciones de alto riesgo (alerta dinámica)

Se inserta en color llamativo solo cuando se acerca un tifón o se emite una alerta especial.

🚨 【IMPORTANTE】Uso durante condiciones meteorológicas adversas Actualmente existen condiciones meteorológicas con riesgo de graves desastres. El análisis de la IA contiene márgenes de error que no son visibles a simple vista. Basar las decisiones de protección civil en esta explicación es extremadamente peligroso. Consulte de inmediato la información más reciente de la Agencia Meteorológica y los avisos de evacuación de su municipio.

Botón de "notificar error" en la interfaz

Además de los avisos, se recomienda incluir un botón de "notificar un error de la IA" (por ejemplo, un icono de pulgar hacia abajo).

Esto tiene un significado que va más allá de una simple función de retroalimentación.

  • Sirve como prueba de que el usuario está usando el servicio con pensamiento crítico (efecto de exención de responsabilidad).
  • Se convierte en datos de prueba para mejorar el prompt en el futuro.
  • Funciona como una señal de UX que previene la confianza excesiva en la IA.

Para ser honesto, el botón de notificación de errores también tiene sus límites. Los usuarios no especializados no pueden notificar errores precisamente porque no son capaces de detectarlos. Este botón solo puede capturar "los errores que alguien logró detectar". Por eso, la interfaz de notificación no es el núcleo de la red de seguridad, sino solo un complemento. El núcleo de la red de seguridad, como se ha repetido, está en "el flujo hacia la información confirmada".

Conclusión: diseñar el "cómo usarlo" más que la "corrección"

A lo largo de tres partes hemos examinado las posibilidades y limitaciones de la IA generativa en el análisis de mapas meteorológicos (dibujados). Hagamos un resumen final.

Lo que actualmente puede delegarse a la IA:

  • Extracción de datos de información textual y figuras en color (de forma limitada)
  • Elaboración de explicaciones basadas en datos textuales existentes
  • Elaboración de listas de verificación con "los puntos que hay que comprobar a continuación"
  • Filtrado primario de contradicciones físicas (de forma auxiliar; no como garantía final)

Lo que actualmente no puede delegarse a la IA:

  • Lectura precisa de mapas de altura en blanco y negro de alta densidad
  • Construcción coherente de la estructura tridimensional entre figuras de distintos niveles
  • Juicio final climatológico y físico
  • La conciencia honesta de "que no puede leer algo" (puede reforzarse con el prompt, pero no es completo)
  • Y delegar en usuarios no especializados el rol de detectar las mentiras

Si se aspira a la implementación práctica, el núcleo del diseño son estos tres puntos:

  1. La veracidad de los datos se garantiza no con la IA, sino con texto estructurado.
  2. La IA actúa como "copiloto", limitándose a la orientación visual y la explicación de contexto.
  3. Las limitaciones no se ocultan: se comunican con transparencia mediante avisos y una interfaz de notificación de errores, y las decisiones importantes se canalizan hacia la información confirmada (oficial de la Agencia Meteorológica).

La mayor diferencia respecto a la primera versión está en el tercer punto. En lugar de delegar la verificación final en "los ojos del usuario", se delega en "la respuesta correcta externa que son los datos confirmados". Dado que los usuarios previstos no son especialistas, esta es la solución más honesta a la que se puede llegar.

No "esperar a que la IA sea perfecta", sino "diseñar un reparto de roles que genere valor asumiendo una IA imperfecta". Este es, a nuestro juicio, el enfoque más realista y honesto posible en el momento actual.

Epílogo: lo que realmente queríamos transmitir con esta serie

Cuando se usa la IA en un campo especializado, lo más peligroso no es "que la IA se equivoque".

Es "que la IA se equivoque con un tono convincente y con total confianza".

La salida que observamos en la Parte 1 — "he verificado que todo es completamente coherente" — habría circulado tal cual como "una explicación correcta" si el usuario no hubiera detectado la contradicción lógica. Y solo un especialista entrenado puede detectarla.

Cuando se integra la IA en el trabajo o en los hobbies, son indispensables dos ruedas: el diseño de prompts que hace que la propia IA exprese sus limitaciones, y el diseño de flujo de trabajo que delega la corrección final en humanos (preferiblemente especialistas) y en información confirmada. Nos alegrará si esta serie sirve de referencia a la hora de pensar en ese tipo de diseños.