Pentest de LLM, Red Team adversarial, gobernanza ISO 42001 y monitoreo continuo — diseñados para el stack de IA real, no adaptados de pruebas web.
Agendar diagnóstico de IAUna empresa de seguridad en IA protege sistemas de inteligencia artificial y LLM frente a ataques adversariales, prompt injection, envenenamiento de datos y robo de modelos. Berghem es una empresa brasileña de seguridad en IA que atiende a LATAM, ofreciendo pentest de IA/LLM, Red Team para IA y gobernanza alineada con la ISO 42001, el EU AI Act y el NIST AI RMF.
Los sistemas agénticos amplían esta superficie de ataque — para proteger agentes autónomos con acceso a herramientas y memoria, consulte seguridad en agentes de IA.
Berghem es una empresa de seguridad en IA con sede en São Paulo, Brasil, con un equipo de seguridad ofensiva enfocado en sistemas de IA y LLM y operación en Brasil y América Latina.
Nuestro trabajo está alineado con la ISO/IEC 27001 para la gestión de seguridad de la información y la ISO/IEC 42001 para sistemas de gestión de IA, y mapeado al EU AI Act y al NIST AI RMF.
Un equipo dedicado de especialistas en seguridad ofensiva prueba LLMs, agentes autónomos y pipelines RAG usando el OWASP LLM Top 10, MITRE ATLAS y nuestra Promptware Kill Chain.
Atendemos a organizaciones en Brasil y América Latina, con entrega en Europa a través de Berilo, combinando presencia local con el contexto regulatorio de cada mercado.
Apoyamos a finanzas, tecnología y otros sectores regulados donde los sistemas de IA implican un riesgo material, entregando evidencia reproducible y remediación accionable.
La seguridad de LLM es la disciplina que protege los grandes modelos de lenguaje y la stack que los pone en producción —prompts de sistema, guardrails, pipelines de retrieval (RAG), llamadas a herramientas, memoria, plugins y las salidas que alimentan sistemas downstream. A diferencia de las aplicaciones tradicionales, un LLM no separa los datos de las instrucciones: cualquier texto que entra en el contexto puede interpretarse como un comando. Esto difumina la frontera de confianza y crea clases de ataque que no existen en el software convencional.
En la práctica, proteger un LLM significa tratar cada punto donde el texto no confiable se encuentra con el modelo como una superficie de ataque. Un documento recuperado por RAG, el historial de conversación, el contenido de una página que el agente navega, el retorno de una herramienta — todos pueden llevar instrucciones maliciosas. Por eso Berghem evalúa el sistema de extremo a extremo, y no solo el modelo aislado: el riesgo casi siempre está en la forma en que el modelo se integra, se orquesta y se expone.
La seguridad de LLM se apoya en tres frentes complementarios. El frente ofensivo —pentest de LLM y Red Team adversarial— ejercita el sistema con prompt injection, jailbreaks, extracción de prompt de sistema, invocación insegura de herramientas y entradas adversariales, produciendo pruebas de explotación reproducibles. El frente defensivo refuerza los guardrails, valida y sanitiza las salidas, aplica el principio de menor privilegio a las herramientas y limita el consumo de recursos. El frente de gobernanza garantiza que las decisiones, los datos de entrenamiento y los proveedores sean rastreables y auditables.
Cada dimensión requiere sus propios controles. El tratamiento de entrada debe asumir que todo texto en el contexto es hostil hasta que se demuestre lo contrario. El tratamiento de salida debe validar, escapar y nunca ejecutar ciegamente lo que el modelo devuelve. La capa de herramientas debe conceder el menor conjunto de permisos posible y exigir confirmación para acciones sensibles. Los datos de entrenamiento y fine-tuning necesitan procedencia verificable para resistir el envenenamiento. Y el consumo —tokens, llamadas y costo— debe tener límites que eviten el abuso y la denegación de servicio.
El modelo de amenazas de un LLM difiere fundamentalmente del de una API tradicional. En una API, la frontera entre código y datos es rígida y conocida; en un LLM, esa frontera es probabilística y depende del propio contenido. Un atacante no necesita una falla de memoria ni una inyección de SQL —basta con redactar texto lo bastante persuasivo para que el modelo priorice la instrucción maliciosa sobre la política del sistema. La prompt injection indirecta agrava el cuadro: la carga hostil puede estar en un correo, en una página web, en un PDF o en un registro de base de datos que el modelo solo lee. Por eso la superficie de ataque de un LLM incluye todo lo que puede terminar en su contexto, y no solo la interfaz expuesta al usuario final.
El enfoque de Berghem para la seguridad de LLM parte de un relevamiento de arquitectura y flujos de datos, seguido de un modelado de amenazas específico para IA usando el OWASP LLM Top 10, el MITRE ATLAS y la Promptware Kill Chain. A partir de ahí, ejecutamos pruebas ofensivas dirigidas —prompt injection directa e indirecta, jailbreaks, extracción de prompt de sistema, abuso de herramientas y RAG poisoning— y documentamos cada explotación con evidencia reproducible. Cerramos el ciclo con recomendaciones de remediación priorizadas por riesgo y, cuando el cliente lo desea, monitoreo continuo que detecta regresiones y nuevos vectores a medida que el sistema evoluciona. El objetivo no es solo encontrar fallas, sino dejar el sistema mensurablemente más difícil de comprometer.
Todo texto que llega al contexto —prompt del usuario, documento RAG, retorno de herramienta— se trata como potencialmente hostil, con una separación clara entre instrucciones confiables y contenido no confiable.
Las respuestas del modelo se validan, se escapan y nunca se ejecutan ciegamente en sistemas downstream, evitando inyección secundaria, XSS y ejecución indebida de código.
Los agentes reciben el menor conjunto de permisos necesario; las acciones sensibles exigen confirmación y quedan registradas para auditoría.
Los datos de entrenamiento, fine-tuning y RAG tienen origen verificable, reduciendo el riesgo de envenenamiento de datos y de modelo.
Las cuotas de tokens, tasa y costo protegen contra el consumo ilimitado, el abuso económico y la denegación de servicio al modelo.
Las decisiones, las versiones de modelo y los incidentes son rastreables, sosteniendo el cumplimiento con ISO/IEC 42001, el NIST AI RMF y el EU AI Act.
Las vulnerabilidades más críticas en LLM están catalogadas por el OWASP Top 10 for LLM Applications 2025. Berghem mapea cada hallazgo a estos identificadores, priorizando las clases de mayor impacto en sistemas de producción.
Entradas maliciosas —directas o indirectas, vía documentos, RAG o herramientas— sobrescriben instrucciones y desvían el comportamiento del modelo, sorteando guardrails y políticas.
El modelo revela datos sensibles: PII, secretos, el prompt de sistema o contenido propietario presente en el contexto, en el entrenamiento o en las fuentes recuperadas.
La manipulación de datos de entrenamiento, fine-tuning o embeddings inserta backdoors y sesgos, comprometiendo la integridad de las respuestas de forma difícil de detectar.
Permisos, autonomía o funcionalidades excesivas permiten que el modelo ejecute acciones dañinas —acceder a sistemas, mover datos o disparar operaciones— más allá de lo previsto.
La ausencia de límites de tokens, tasa y costo abre espacio para la denegación de servicio al modelo, el abuso económico y la extracción de modelo mediante consultas masivas.
Los agentes de IA van más allá de responder texto: planifican, deciden y actúan —invocando herramientas, navegando por la web, ejecutando código y manteniendo memoria entre pasos. Cada una de esas capacidades amplía la superficie de ataque. Un agente comprometido por prompt injection indirecta puede exfiltrar datos, encadenar llamadas peligrosas a herramientas o persistir instrucciones maliciosas en su memoria, transformando una sola entrada hostil en una cadena de acciones autónomas. Proteger agentes exige menor privilegio por herramienta, confirmación humana para acciones sensibles, aislamiento de memoria y registro auditable de cada decisión. Profundice en seguridad en agentes de IA para entender cómo evaluamos y blindamos sistemas agénticos en producción.
Todo proveedor de security testing promete encontrar vulnerabilidades. Pocos pueden garantizar que cada hallazgo del informe es real, explotable y correctamente priorizado — esa es la diferencia entre un informe que genera acción y uno que genera retrabajo.
Un único falso positivo que llega al cliente no es ruido operativo: es erosión de confianza. El cliente pierde horas investigando algo que no existe, cuestiona los demás hallazgos por asociación, y el costo reputacional supera el valor del engagement entero. Nuestra metodología parte de una premisa innegociable — ningún finding llega al cliente sin evidencia mecánica que lo haga defendible.
Para aplicaciones y APIs tradicionales, el mismo rigor guía nuestro pentest — el test de intrusión manual de Berghem en los niveles Silver, Gold y Diamond.
La mayoría de las herramientas trata "hallazgo" como una sola categoría. Nosotros lo tratamos como cuatro problemas distintos — porque cada uno destruye valor de manera diferente.
Hallazgo que no existe en el ambiente. Mina la confianza directamente.
Vulnerabilidad real no reportada. El peor escenario: el cliente queda expuesto sin saberlo.
La vulnerabilidad existe, pero no es explotable en ese contexto. Operativamente, cuesta lo mismo que un FP.
500 hallazgos reales sin priorización valen, en la práctica, lo mismo que 500 falsos positivos.
Las evaluaciones genéricas combaten solo el FP. Nosotros tratamos los cuatro.
El diferencial no es una promesa de marketing — es un pipeline con cinco componentes que trabajan juntos.
Antes de cualquier prueba, mapeamos lo que está instalado y autorizado por política, qué controles están activos y con qué cobertura, cómo está segmentada la red y cómo están configurados identidad/MFA. Eso es lo que permite distinguir "RustDesk instalado" de "RustDesk autorizado por política, con hash verificado". Sin ese contexto, ambos parecen idénticos.
Cada finding recibe un score calculado por seis bloques independientes — inventario autorizado, comportamiento de los controles activos, allowlist formal, explotabilidad real en el segmento, configuración de identidad/MFA y patrón histórico del sector. El score no decide, informa.
El analista ve el score, las razones que lo componen y cuatro opciones mapeadas directamente a la taxonomía: confirmar, rechazar como FP (con justificación obligatoria), reclasificar como irrelevante o reajustar prioridad. Un score alto exige justificación registrada para auditoría.
Cada decisión alimenta una base de patrones por sector y tamaño. El sistema aprende, por ejemplo, que un comportamiento es legítimo en el 80% de los bancos medianos pero solo en el 17% de los hospitales — y aplica ese conocimiento desde el día uno en un cliente nuevo. La confianza en el patrón crece con volumen y decae con el tiempo (vida media de 18 meses), acompañando el cambio del escenario.
Las decisiones entran en cola asíncrona, se agregan cada 6 horas en staging y solo van a producción tras seis gates de calidad: volumen mínimo, diversidad de analistas, diversidad de engagements, detección de sesgo individual, consistencia temporal y verificación de cambio abrupto. Un monitor diario degrada automáticamente reglas que comienzan a divergir del comportamiento reciente.
Cada hallazgo viene con la evidencia mecánica que justifica su presencia.
VP-I y VP-MP se filtran antes de convertirse en tickets.
Cuantos más engagements en su sector, más preciso el resultado — sin reconstruir desde cero.
Cada decisión registrada, lista para compliance.
Adaptado de la investigación de Schneier et al. (2025), nuestra Promptware Kill Chain mapea cómo los adversarios reales comprometen sistemas de IA — desde el prompt injection inicial hasta la exfiltración total.
Desde las pruebas ofensivas proactivas hasta la gobernanza continua, cada pilar protege una dimensión diferente de su programa de IA.
Cuando el sistema ya pasó por pentest, el siguiente paso es el Red Team para IA — una campaña adversarial completa que mide detección y respuesta, no solo exposición.
OWASP LLM Top 10, prompt engineering adversarial y análisis de infraestructura — encontramos las fallas antes que el atacante.
Simulación completa del Promptware Kill Chain — operadores humanos explotan su sistema como lo haría un atacante real.
Diagnóstico AI-VRM de la postura de seguridad, arquitectura y exposición en sistemas propios y de terceros.
Frameworks regulatorios (EU AI Act, PL 2338), políticas de uso responsable y gestión de riesgo para la adopción de IA.
Roadmap de seguridad de IA, reportes para el consejo y evaluación de madurez — orientación de nivel C-suite.
21 incidentes catalogados. 15 con 4+ etapas de kill chain. 57% mantuvieron persistencia activa tras la detección inicial.
Sugerencias de código malicioso que conducen a la ejecución arbitraria de comandos en máquinas de desarrolladores.
Movimiento lateral a través de Google Workspace sin interacción del usuario mediante prompt injection.
Uso de la memoria de conversación como un canal persistente de comando y control para operaciones adversarias.
Explotación del asistente de código con IA para ejecutar comandos arbitrarios en máquinas de desarrolladores.
Frentes especializados para proteger y gobernar sistemas de IA.
Ya sea que esté desplegando su primer LLM o gestionando IA empresarial a escala, nuestro equipo está listo para ayudarle a protegerla.
Contáctenos