OSINT con LLMs: como convertir web search en evidencia verificable
Como diseno sistemas OSINT con LLMs y busqueda web: fuentes, evidencia, confianza, seguridad, evaluacion y revision humana.
Buscar informacion publica con un LLM parece sencillo: se formula una pregunta, el modelo consulta la web y devuelve una respuesta bien redactada. El problema es que una respuesta convincente no es necesariamente una respuesta demostrada.
En proyectos de IA y automatizacion he trabajado con herramientas de web search integradas en LLMs para investigar informacion publica y convertirla en resultados que otras personas o sistemas puedan utilizar. Este tipo de trabajo se acerca al OSINT, u Open Source Intelligence: obtener conocimiento util a partir de fuentes abiertas.
La parte dificil no es encontrar texto relacionado. Es conservar la relacion entre cada afirmacion, su fuente y el nivel de confianza que realmente merece.
Respuesta directa: como debe funcionar un sistema OSINT con LLMs
Un sistema OSINT fiable con LLMs debe definir la pregunta, buscar en varias fuentes publicas, extraer hechos con sus citas, contrastar contradicciones, separar evidencia de inferencias y entregar un resultado revisable.
Mi arquitectura de referencia tiene siete pasos:
- convertir la necesidad de negocio en preguntas verificables;
- planificar consultas y fuentes relevantes;
- recuperar contenido publico de forma responsable;
- extraer afirmaciones estructuradas con evidencia;
- contrastar y asignar confianza;
- aplicar controles de seguridad y privacidad;
- generar un informe con enlaces y limitaciones explicitas.
El LLM ayuda a buscar, leer y organizar. La evidencia sigue estando en las fuentes.
Que es OSINT y que cambia al incorporar un LLM
OSINT es la recopilacion y analisis de informacion obtenida legalmente de fuentes publicas. Puede incluir webs corporativas, registros oficiales, noticias, informes, repositorios, publicaciones academicas o perfiles profesionales publicos.
Un LLM aporta velocidad en tareas que antes requerian mucho trabajo manual:
- transformar una pregunta amplia en consultas concretas;
- resumir documentos largos;
- extraer nombres, fechas, relaciones o eventos;
- comparar como distintas fuentes describen un mismo hecho;
- traducir contenido;
- producir una primera sintesis legible.
Pero tambien introduce riesgos nuevos. El modelo puede completar huecos con informacion plausible, mezclar fechas, perder matices, confiar en una fuente debil o interpretar una instruccion maliciosa incluida dentro de una pagina. Por eso no utilizaria un LLM como fuente primaria ni aceptaria un informe sin trazabilidad.
De una pregunta ambigua a hechos verificables
Una peticion como esta es demasiado abierta:
Investiga esta empresa y dime si parece fiable.
"Fiable" puede significar muchas cosas. Antes de buscar, dividiria la solicitud en preguntas que se puedan responder con evidencia:
- ¿La entidad aparece en registros oficiales?
- ¿Quienes figuran publicamente como responsables?
- ¿Que productos o servicios declara ofrecer?
- ¿Existen noticias relevantes recientes?
- ¿Las distintas fuentes coinciden en ubicacion, actividad y fechas?
- ¿Que informacion no ha sido posible verificar?
Esta descomposicion reduce el espacio para interpretaciones arbitrarias. Tambien permite decidir que fuentes son adecuadas para cada pregunta y cuando el sistema debe reconocer que no tiene respuesta.
La jerarquia de fuentes importa
No todas las paginas encontradas tienen el mismo valor probatorio. Una jerarquia inicial podria ser:
| Nivel | Tipo de fuente | Uso habitual |
|---|---|---|
| 1 | Registros, organismos y documentos oficiales | Confirmar identidad, fechas o informacion regulada |
| 2 | Web corporativa, documentacion tecnica y repositorios propios | Entender lo que una entidad declara sobre si misma |
| 3 | Medios reconocidos, publicaciones academicas e informes sectoriales | Aportar contexto y verificacion independiente |
| 4 | Directorios, agregadores, foros y redes sociales | Descubrir pistas que deben contrastarse |
La fuente mas alta no siempre contiene toda la verdad, pero si cambia el peso de una afirmacion. Una descripcion comercial publicada por una empresa sirve para conocer su posicionamiento; no demuestra por si sola que todos sus resultados sean ciertos.
Tambien conservaria la fecha de publicacion o consulta. La web cambia, y una afirmacion correcta hace dos anos puede estar desactualizada hoy.
El objeto central no es el resumen: es la afirmacion con evidencia
En lugar de pedir al modelo solamente un parrafo final, haria que cada hallazgo importante se represente de forma estructurada:
{
"claim": "La organizacion declara operar en dos mercados europeos.",
"source_url": "https://example.com/about",
"source_type": "official_website",
"published_at": null,
"retrieved_at": "2026-06-11",
"evidence": "Fragmento breve que respalda la afirmacion",
"confidence": "medium",
"status": "self_reported"
}
Esta estructura obliga a distinguir varias cosas:
- afirmacion: que se cree que es cierto;
- evidencia: que parte concreta de una fuente la respalda;
- procedencia: de donde sale y cuando se consulto;
- confianza: cuanto respaldo existe;
- estado: si es un hecho confirmado, una declaracion propia o una inferencia.
Despues se puede generar un resumen, una tabla o una alerta. Pero el resultado legible nace de datos auditables, no al reves.
Como gestionaria contradicciones y confianza
Si dos fuentes contradicen una fecha, un nombre o una cifra, el sistema no deberia elegir silenciosamente la opcion que parezca mas probable. Deberia registrar ambas versiones, evaluar la calidad y actualidad de cada fuente y mostrar el conflicto.
Una puntuacion de confianza puede combinar criterios como:
- autoridad y proximidad de la fuente al hecho;
- numero de fuentes independientes que coinciden;
- actualidad de la informacion;
- presencia de evidencia textual directa;
- consistencia con registros o documentacion oficial;
- ausencia de contradicciones relevantes.
No convertiria esa puntuacion en una verdad matematica. Sirve para ordenar revision y comunicar incertidumbre, no para ocultarla.
| Confianza | Interpretacion operativa |
|---|---|
| Alta | Varias fuentes fiables e independientes coinciden |
| Media | Existe evidencia util, pero depende de una fuente o quedan dudas |
| Baja | Es una pista, inferencia o dato sin corroboracion suficiente |
Las afirmaciones de baja confianza pueden seguir siendo utiles para orientar una investigacion, pero no deberian activar decisiones importantes de forma automatica.
Seguridad: una pagina web tambien puede atacar al agente
Cuando un LLM lee contenido externo, ese contenido debe tratarse como datos no confiables. Una pagina puede incluir instrucciones dirigidas al modelo, texto oculto o contenido disenado para manipular el resultado. Es una forma de prompt injection indirecta.
Aplicaria controles como:
- separar claramente instrucciones del sistema y contenido recuperado;
- impedir que una pagina pueda cambiar el objetivo o las herramientas permitidas;
- limitar acciones del agente a una lista explicita;
- validar URLs, tipos de archivo y tamanos;
- no ejecutar codigo encontrado durante la investigacion;
- registrar consultas, fuentes y decisiones;
- exigir confirmacion humana antes de cualquier accion con impacto.
El agente puede proponer que una fuente merece atencion. No deberia adquirir permisos nuevos porque una web se lo pida.
Privacidad y uso responsable
Que una informacion sea accesible publicamente no significa que cualquier tratamiento sea proporcionado. Un sistema OSINT responsable debe tener una finalidad legitima, minimizar datos y respetar las condiciones legales y eticas aplicables.
En un entorno empresarial, definiria antes de empezar:
- que pregunta concreta se necesita resolver;
- que categorias de fuentes estan autorizadas;
- que datos personales no deben recopilarse;
- cuanto tiempo se conservaran resultados y evidencias;
- quien puede acceder al informe;
- que decisiones requieren revision humana;
- como corregir informacion incorrecta o desactualizada.
Tambien evitaria convertir senales publicas debiles en perfiles o conclusiones sensibles. La capacidad tecnica para recopilar informacion no sustituye el criterio sobre si debe recopilarse.
Arquitectura tecnica de referencia
Un flujo generico podria tener esta forma:
Pregunta y politica de investigacion
-> planificador de consultas
-> proveedor de web search
-> recuperacion y limpieza de documentos
-> extraccion de afirmaciones y citas
-> contraste, deduplicacion y confianza
-> revision humana o informe final
Separaria responsabilidades para poder probar y sustituir componentes:
- el planificador convierte objetivos en consultas;
- el buscador devuelve candidatos y metadatos;
- el recuperador obtiene solo el contenido necesario;
- el extractor produce afirmaciones estructuradas;
- el verificador compara fuentes y marca contradicciones;
- el generador redacta sin perder citas ni limitaciones.
Dependiendo del contexto, utilizaria un workflow para orquestar pasos y servicios backend para la logica que debe ser estable y testeable. Es el mismo criterio que explico en n8n, FastAPI o Spring: como elijo arquitectura para una automatizacion con IA.
Como evaluaria el sistema
Un sistema de busqueda no se evalua solamente comprobando si la respuesta "suena bien". Crearia un conjunto de investigaciones con resultados conocidos y mediria:
- precision factual: cuantas afirmaciones son correctas;
- cobertura: cuantos hechos relevantes recupera;
- calidad de citas: si la evidencia realmente respalda la afirmacion;
- calidad de fuentes: si prioriza fuentes adecuadas;
- deteccion de conflictos: si identifica versiones incompatibles;
- calibracion: si expresa poca confianza cuando la evidencia es debil;
- actualidad: si distingue informacion reciente de contenido antiguo;
- resistencia a prompt injection: si ignora instrucciones procedentes de paginas.
Tambien revisaria falsos positivos. En OSINT, una coincidencia de nombre o una inferencia demasiado rapida puede causar mas dano que omitir una pista secundaria.
Ejemplo practico sin datos sensibles
Imaginemos que un equipo necesita preparar una ficha publica sobre un posible proveedor. El objetivo no es decidir automaticamente si debe contratarse, sino reunir evidencia para una revision humana.
El sistema podria:
- confirmar la identidad juridica en fuentes oficiales;
- localizar la web y documentacion declarada por el proveedor;
- buscar noticias recientes y menciones sectoriales;
- extraer productos, ubicaciones y responsables publicados;
- detectar diferencias entre fuentes;
- generar una cronologia con citas;
- indicar claramente que puntos siguen sin verificar.
La salida adecuada no seria un veredicto opaco de "fiable" o "no fiable". Seria un informe corto, con hechos respaldados, contradicciones visibles y preguntas pendientes para que una persona tome una decision informada.
Lo que he aprendido construyendo con web search y LLMs
Cuanto mejor escribe un modelo, mas importante es exigirle evidencia. La fluidez puede facilitar la lectura, pero tambien puede ocultar que una conclusion depende de una unica fuente o de una inferencia fragil.
Por eso mi principio para estos sistemas es sencillo:
El LLM puede acelerar la investigacion, pero cada conclusion importante debe poder volver a su fuente.
Este enfoque conecta con otros proyectos donde he utilizado automatizacion para analizar mucha informacion y priorizar decisiones, como el sistema con el que analice aproximadamente 10.000 ofertas de empleo. La tecnologia aporta velocidad; la estructura, la evidencia y la revision aportan confianza.
Puedes consultar mas articulos sobre IA y automatizacion en el blog o contactar conmigo desde la pagina de contacto.