Cuándo, cómo y a qué coste tiene sentido apoyarse en IA durante un pentest.
En los últimos años, la inteligencia artificial ha pasado de ser una curiosidad puntual en el mundo de la seguridad ofensiva a convertirse en una parte cada vez más recurrente del flujo de trabajo de muchos pentesters. El ritmo de publicaciones académicas, frameworks open source y herramientas comerciales que orbitan alrededor de “pentesting con IA” se ha disparado, y la lista sigue creciendo.
Este artículo no pretende entrar en el debate de si la IA va a reemplazar a los pentesters humanos. Esa discusión está saturada y, con honestidad, distrae del problema real, que es bastante más concreto: cuándo, cómo y a qué coste tiene sentido apoyarse en IA durante un pentest. Lo que sí intentamos aquí es revisar los principales enfoques que se están utilizando, evaluar pros y contras de cada uno, hablar de los componentes arquitectónicos que marcan la diferencia entre una herramienta útil y un quema-tokens, y compartir algunas ideas prácticas sobre cuándo compensa cada vía.
El contenido expuesto a continuación está basado en la experiencia propia del equipo que formamos Kaptor Security. No solo desde pruebas de herramientas de terceros, sino también desde el desarrollo de nuestras propias soluciones internas, que apoyan nuestro trabajo diario y que hemos ido construyendo a lo largo de nuestra trayectoria en ciberseguridad e inteligencia artificial como parte de una evolución continua.
Hay dos variables que son transversales a todo lo demás y conviene dejarlas claras desde el principio.
La primera es la calidad del modelo subyacente. La capacidad de los modelos para razonar, mantener la coherencia en tareas largas, generar payloads creativos y entender el contexto técnico marca una diferencia enorme. En la práctica, los modelos que destacan en programación tienden a destacar también en pentesting, porque buena parte del trabajo, como entender stack traces, escribir scripts ad-hoc, leer respuestas raras de un servidor o encadenar primitivas, es razonamiento sobre código y protocolos. Los modelos frontera de los grandes laboratorios marcan una diferencia clara frente a alternativas más pequeñas, no solo en desempeño bruto, sino en estabilidad: alucinan menos, tienden a no sobreestimar tanto el impacto, abandonan antes las vías muertas (líneas de investigación que no llevan a ningún hallazgo) y mantienen mejor el hilo en sesiones largas.
La segunda variable es el coste. El gasto en tokens depende mucho de la combinación entre el modelo elegido, la arquitectura sobre la que corre y el tipo de tarea. Usar un modelo frontera con todo el contexto de un pentest serio en una arquitectura agéntica que itera durante horas no se parece nada a una consulta puntual al chat para un payload concreto. Lo que sí se mantiene como patrón estable es algo más cualitativo: un humano experimentado prioriza con un criterio que el agente todavía no replica de forma fiable, y por eso cada token consumido en vías muertas o en exploraciones incoherentes acaba traduciéndose en facturas descontroladas. La economía cambia mucho según seas una organización con presupuesto industrial o un pentester individual jugando con tu API key, y conviene tener esto presente al evaluar cualquiera de los enfoques que vienen a continuación.
Los casos de uso son muy distintos: no es lo mismo querer que la IA te haga un pentest completo y autónomo, que usarla como complemento para tareas concretas. En la mayoría de los casos personales, salvo que tengas mucho presupuesto, intentar lo primero te saldrá carísimo y mediocre, y te venderán la moto con cualquiera de las “soluciones definitivas” que aparecen cada semana.
Aunque sea evidente, no está de más incluir el uso más básico de la IA para pentesting: el chat. Así empezamos todos y, en mayor o menor medida, todos seguimos practicándolo. Le pasas contexto, sea un endpoint extraño, un fragmento de código o una respuesta del servidor, le pides una opinión, payloads concretos, un script ad-hoc, información sobre un framework, ideas de vías de ataque. La IA es completamente pasiva. Tú eres el sujeto activo: ejecutas, observas, decides.
Este modo es directo y no introduce riesgos de scope, ya que la IA no toca el target. Su límite está en que toda la carga cognitiva sigue siendo tuya: no hay continuidad entre conversaciones, no hay memoria del engagement, no hay automatización. Aun así, tiene su sitio para tareas concretas como escribir un payload polyglot, entender un binario raro, generar un wordlist contextual o redactar un POC, donde un buen modelo en una ventana de chat aporta valor inmediato sin la complejidad ni el coste de las arquitecturas que veremos después.
La idea aquí es coger un escáner determinista, como un fuzzer o un detector clásico de XSS, SQLi o SSRF, y delegar en la IA solo decisiones puntuales donde la creatividad o el contexto importan. Por ejemplo, un escáner que para detectar XSS primero comprueba de forma determinista si el payload se refleja, analiza el contexto donde aparece (HTML, atributo, JavaScript...) y entonces le pide a la IA que proponga payloads adaptados a ese contexto exacto. El escáner se encarga del envío, la verificación, los reintentos finitos y la gestión de sesión, mientras que la IA solo aporta creatividad acotada en una decisión muy concreta.
Este enfoque es relativamente barato comparado con los que veremos después para el caso de un pentest autónomo. El problema es que, en la práctica, aprovecha muy poco lo que la IA puede aportar. La capacidad de adaptarse a contextos diversos, encadenar razonamientos sobre comportamientos extraños del servidor, o entender cuándo dos hallazgos aparentemente independientes se combinan en una vulnerabilidad seria, queda fuera del bucle por diseño. La IA solo entra en una rendija muy estrecha del flujo, y la mayor parte del trabajo lo sigue haciendo el código determinista de siempre. El resultado es que, comparado con un pentest clásico sin IA, este enfoque suele aportar mejoras marginales, como payloads ligeramente más creativos para una clase concreta de vulnerabilidad, sin que se note demasiado en la cobertura ni en la calidad final del informe. A esto se suma que requiere ingeniería específica por cada tipo de vulnerabilidad, lo que limita su escalabilidad y termina haciendo que cada nueva clase de bug sea un proyecto en sí mismo.
Aquí es donde empieza la fiesta y, a la vez, la mayoría de los problemas de coste/beneficio. La idea es enchufar al modelo un conjunto de herramientas, directamente o vía MCP, y dejarle un prompt amplio para que las use libremente hasta cumplir el objetivo. En el ecosistema actual existen ya varios servidores que exponen cientos de herramientas ofensivas (Nmap, gobuster, sqlmap, nuclei, hashcat, etc.) listas para que cualquier cliente LLM compatible las invoque de forma autónoma.
En la práctica, este modo sufre cuatro problemas recurrentes que cualquiera que lo haya probado durante unas pocas horas reconoce:
nmap -A ya te come miles de tokens, multiplícalo por veinte intentos.Para un pentester individual, el modo agéntico básico tiende a no compensar a menos que se le acote a tareas muy específicas, como “enumera subdominios de este target y clasifícalos por interés” o “prueba variaciones de payloads...”. Como herramienta de pentest completo a base de un único prompt, sigue siendo bastante decepcionante en proporción a lo que cuesta.
El siguiente paso, que es donde está concentrada la mayor parte de la investigación académica reciente, consiste en añadir una capa de planificación. Un orquestador genera un plan, descompone el objetivo en subtareas, y delega cada una en agentes especializados: uno experto en reconocimiento, otro en análisis de vulnerabilidades, otro en explotación (XSS, SQLi...), otro en post-explotación, etc. En la literatura han ido apareciendo distintas formas de estructurar este plan: árboles de testing, grafos de tareas, máquinas de estados de pentesting, resúmenes de situación, memorias jerárquicas con activación localizada de contexto, planificación en dos fases que combina CVEs con keywords del target... También se han propuesto arquitecturas multi-agente con roles diferenciados (reconnaissance agent, vulnerability analysis agent, exploitation agent), y orquestadores especializados por dominio: pentest web, escalada de privilegios, red team, etc.
Esta vía está, en teoría, bien razonada: mimetiza la división de trabajo que hace un equipo humano. En la práctica, presenta tres problemas recurrentes:
Los planes están excesivamente influenciados por los prompts de planificación. Como pentester con experiencia, ves al orquestador encarrilando el flujo por una vía que ya sabes que no va a llegar a ningún sitio, y aun así el agente la sigue porque “toca según el plan”. Hay tareas innecesarias que ningún humano haría, y vías obvias que el orquestador descarta porque no encajan en su esquema mental. Las evaluaciones publicadas en el último año lo han documentado de forma cruda [7]: los agentes lo hacen razonablemente bien en tareas focalizadas, pero se degradan notablemente cuando tienen que priorizar bajo incertidumbre y abandonar líneas de ataque fallidas. Donde un humano pivota, el agente itera variaciones de la misma aproximación. Y el problema es que en la traza no parece un fallo: las salidas siguen siendo fluidas y los comandos plausibles.
El gasto de tokens crece de forma no lineal. Una arquitectura bien diseñada permite “salirse del plan” cuando aparece algo prometedor, pero cada subagente mantiene su propio contexto, los outputs de herramientas son verbosos, y la coordinación entre el orquestador y los especialistas tiene un coste fijo no despreciable. Un pentest medianamente largo puede multiplicar por diez o veinte el gasto frente al modo conversacional.
La fase de reconocimiento es un cuello de botella brutal. Una parte del recon puede apoyarse en herramientas clásicas como crawlers, escaneo de puertos o fuzzers de directorios, y otra en componentes con inteligencia más fina, como navegación dirigida con Playwright impulsada por la IA para recorrer flujos de aplicación, identificar endpoints relevantes o mantener sesiones complejas. Pero al final, los dos caminos convergen en lo mismo: una cantidad considerable de información (requests, responses, estructuras de URL, parámetros, comportamientos observados, relaciones lógicas entre endpoints) que el modelo tiene que ingerir, filtrar e interpretar para construir un mapa útil del target. Si esto no se optimiza con mucho cuidado, te puedes gastar el sueldo del mes solo en la fase de descubrimiento, y la mayor parte del contexto que entra al modelo será ruido.
¿Cuándo compensa entonces este enfoque? Si eres una organización con presupuesto industrial para combinar el uso intensivo de modelos frontera con una inversión seria de ingeniería que realmente optimice el reconocimiento, la memoria y la verificación de hallazgos. Para uso personal, si ya eres un pentester experimentado, actualmente suele salir caro frente al beneficio. Y si te dejas llevar por la tentación de abaratarlo tirando de modelos de bajo coste, acabarás sacrificando una parte considerable de tu tiempo descartando ruido para llegar a un puñado de hallazgos puntuales que probablemente habrías encontrado por la vía clásica con menos esfuerzo y recursos.
Esta es, en mi opinión y la de buena parte de la literatura aplicada, la vía más sensata para un pentester individual que quiere integrar IA en su trabajo. La idea es construir una arquitectura donde el humano está en el bucle desde el inicio, no como un fallback de emergencia.
El flujo conceptual es algo así:
La razón por la que esto funciona tan bien es la misma por la que la mayoría de agentes de código modernos exigen aprobación explícita para cada cambio multi-fichero, y por la que la propia experiencia operativa con agentes en producción a lo largo de 2025 ha desembocado, casi sin excepción, en lo mismo: las organizaciones que han intentado quitar al humano del bucle antes de tener garantías de observabilidad y corrección han tenido los peores resultados. Investigaciones recientes sugieren que cuando los humanos editan la salida generada por la IA, la calidad final es notablemente mayor que cuando se limitan a aceptar o rechazar binariamente lo que el modelo propone [2]. El acto de editar implica al pensamiento crítico de un modo que el aprobar/rechazar no consigue.
En pentesting esto importa especialmente porque las acciones son irreversibles y de alto impacto: borrar registros, modificar datos, lanzar ataques que pueden tirar el servicio, exfiltrar información sensible. Distinguir acciones reversibles de irreversibles, y poner checkpoints solo donde añaden valor, es probablemente el principio de diseño más importante de toda la arquitectura HITL.
Una nota interesante: muchas herramientas se venden como “autónomas” pero en su núcleo siguen siendo HITL, porque operan sobre un cliente LLM externo que mantiene la interacción con el operador. La diferencia con un copiloto bien diseñado no es la presencia o ausencia de humano, sino dónde y cómo se inserta. Revisar comandos uno a uno cansa y se acaba haciendo mal. Aprobar líneas de investigación con análisis previo, en cambio, aporta valor real.
Una vía que ha emergido con mucha fuerza durante 2025 y 2026, y que merece su propia sección, es el uso de agentes de código generalistas, como Claude Code, Cursor, Aider, OpenCode, Codex y similares, como base para el pentesting. La idea es interesante: estos agentes ya saben moverse en una terminal, encadenar comandos, leer y escribir ficheros, mantener sesiones largas, y tienen un buen razonamiento sobre código. Si les das las herramientas de seguridad y un sistema de “skills” o subagentes especializados, te ahorras buena parte de la ingeniería de scaffolding.
El atractivo de este enfoque es doble. Primero, el coste de entrada es bajo: una skill o un subagente es habitualmente un fichero de markdown, no una librería en Python con su scaffolding. Segundo, hereda toda la madurez del agente subyacente en cuanto a gestión de contexto, ejecución de comandos, manejo de errores, y la propia evolución del modelo. Cuando sale un Claude o un Codex mejor, todos tus skills mejoran a la vez.
La contrapartida es que estás reutilizando un agente diseñado para programar, no para atacar sistemas. Para que se comporte bien en un contexto ofensivo y sea realmente útil a lo largo del ciclo de vida de un pentest, no basta con lanzarle un prompt. Hay que diseñar el proyecto aprovechando toda la cobertura que ofrecen los agentes de código modernos: ficheros de instrucciones de proyecto como CLAUDE.md, AGENTS.md o equivalentes, skills (SKILL.md), hooks pre/post acción, comandos personalizados, herramientas, subagentes especializados, permisos, etc. Bien usados, estos mecanismos permiten convertir el agente generalista en un compañero con un comportamiento y unas habilidades enfocadas al pentesting. Y no solo desde el punto de vista de la metodología técnica, como qué herramientas usar, qué clases de vulnerabilidad explorar primero, o cómo interpretar ciertos comportamientos del target, sino también desde la operativa: cómo organizar las salidas que va generando, dónde guardar los hallazgos, qué se persiste de cada vía de investigación, qué se descarta, cómo retomar el trabajo en la siguiente sesión.
Aquí es donde se conecta de forma natural con el enfoque 5: los mecanismos de hooks, comandos y subagentes encajan muy bien con un flujo HITL en el que el operador propone, revisa, aprueba y deja que el agente ejecute. Bien diseñado, este patrón permite obtener lo mejor de los dos mundos: la madurez operativa de los agentes de código generalistas, y los puntos de control humanos que evitan que se vaya por vías sin sentido o que reporte alucinaciones como hallazgos. Es, probablemente, uno de los enfoques más prometedores a día de hoy para un pentester individual que quiera integrar IA en serio en su trabajo, aunque sigue requiriendo ingeniería de contexto y curación propia para que el comportamiento del agente esté realmente alineado con el ámbito ofensivo.
Hay, además, una consideración práctica que no es menor: la elección del agente determina con qué proveedor de modelo te casas. Usar Claude Code te ata a Anthropic y a su pricing por token, y usar Codex te ata a OpenAI y al suyo. Como hemos visto últimamente, los precios, los límites de cuota, las políticas de uso e incluso la disponibilidad de los modelos pueden cambiar de un mes para otro, y eso afecta directamente a la viabilidad económica de tu setup. Plantearse, en paralelo o como alternativa, agentes agnósticos del proveedor como OpenCode, que permiten conectar distintos modelos a través de distintas APIs, es a día de hoy una decisión de diseño casi tan relevante como la propia configuración del proyecto. Mantener la capacidad de cambiar el modelo que corre detrás del agente sin reescribir todo tu setup es un seguro barato contra cambios que no controlas.
Independientemente del enfoque, hay un puñado de decisiones arquitectónicas que separan una herramienta útil de una que se te va de las manos.
Un pentest no termina en una sesión. Hay engagements de semanas, hallazgos que se relacionan con otros días después, identificadores que descubres en la fase 2 y resultan clave en la fase 5. Cualquier sistema de IA aplicado a pentesting tiene que poder responder a:
La literatura ha respondido con varias estructuras: el Penetration Testing Tree de PentestGPT [3], el Penetration Memory Tree de TermiAgent [5], que activa la memoria de forma localizada en lugar de inyectar el árbol entero al contexto, el Penetration Task Graph de VulnBot [4], la State Machine de AutoPT, los Situation Summaries de AutoAttacker. Todos atacan el mismo problema desde ángulos distintos: cómo mantener un estado externo al modelo que se pueda consultar, actualizar y resumir sin saturar el contexto. La separación clásica entre memoria a corto plazo, que es la ventana de contexto activa, y memoria a largo plazo, que es un almacenamiento externo persistente con búsqueda semántica, es esencial. Ningún sistema serio debería confiar en que el modelo recuerde lo que pasó hace 50 turnos.
Conviene además distinguir tres tipos de memoria, prestados de la psicología cognitiva pero útiles aquí: episódica, que registra qué pasó y cuándo (por ejemplo, “el endpoint X devolvió un 500 con el payload Y el martes”), semántica, que guarda conocimiento generalizado (“esta API usa JWT con el algoritmo HS256”), y procedimental, que guarda cómo hacer cosas (“para esta aplicación, la sesión se mantiene con cookie SESSIONID renovada cada 15 min”). Los agentes que combinan los tres suelen comportarse mucho mejor en engagements largos.
Una nota crítica: la memoria persistente es también una superficie de ataque [6]. Un agente con memoria que se puede leer y reescribir puede ser envenenado entre sesiones o accedido sin autorización, y en un contexto de pentesting eso es especialmente delicado: ahí es donde están almacenados los datos más sensibles del engagement.
El contexto es un recurso restringido y caro. Un agente que recibe outputs de herramientas verbosos sin filtrar acabará alcanzando el límite de la ventana, gastando una fortuna en tokens y degradando su propia atención. Por eso, en cualquier arquitectura agéntica seria, la gestión del contexto deja de ser un detalle de implementación y se convierte en una parte central del diseño.
Las ideas que mejor funcionan en la práctica giran alrededor de tres principios. Primero, no inflar el contexto con información que ya ha cumplido su propósito: si una herramienta nos confirmó que un puerto está abierto, no necesitamos mantener el output completo del scan dando vueltas durante el resto del engagement. Segundo, resumir y archivar las fases ya completadas en memoria externa antes de que el contexto se sature, manteniendo en la ventana activa solo lo que es directamente relevante para lo que se está haciendo ahora. Y tercero, particionar el trabajo en subagentes con contextos limpios cuando una tarea concreta puede resolverse de forma autónoma y solo necesitamos devolver al coordinador el resultado, no toda la traza.
Una idea que conviene tener presente desde el principio, porque condiciona muchas decisiones de diseño: cuanto mejor desempeña un modelo en tareas de ciberseguridad, menos aporta, y más puede llegar a restar, cargarle en los prompts metodologías muy detalladas basadas en cómo lo haríamos nosotros. La analogía con la programación lo deja claro. Si a un modelo frontera en programación le explicas paso a paso cómo aplicar un algoritmo de backtracking, no le estás enseñando nada que no sepa, y en muchos contextos puedes estar forzándole una secuencia rígida que el problema concreto no necesita.
En pentesting pasa exactamente lo mismo. Aplicar nuestro conocimiento como pentesters aporta valor cuando sirve para acotar el alcance, marcar prioridades, dar contexto del target o transferir hallazgos previos. Pero llenar el prompt de pasos a seguir, listas de comprobaciones detalladas y metodologías cerradas, sobre todo con modelos que ya saben de pentesting por su cuenta, suele acabar mermando su capacidad de adaptarse, de encontrar caminos no obvios y de aplicar su propio criterio experto. Llamémoslo “over-prompting”. La idea no es no guiar al modelo, sino no sustituir su razonamiento por una receta.
Probablemente el problema más subestimado. Los modelos pueden afirmar, y lo hacen con frecuencia, que han encontrado credenciales válidas que en realidad son inventadas, dar por explotada una vulnerabilidad cuando la respuesta no se interpretó correctamente, o presentar como sensible información que es pública.
La magnitud práctica de esto se ve en datos del ecosistema. El proyecto curl, después de años de funcionar un programa de bug bounty productivo, decidió cerrarlo en enero de 2026 porque la avalancha de reportes generados por IA, con vulnerabilidades inventadas, funciones inexistentes y exploits que no funcionaban, hizo que la tasa de hallazgos genuinos cayese a alrededor del 5% [8]. Es un ejemplo extremo, pero ilustra qué pasa cuando se acepta la salida de un modelo sin una capa seria de verificación.
Las arquitecturas que se toman esto en serio incorporan una fase de validación determinista después de cada hallazgo significativo. Por ejemplo, si el agente afirma haber explotado un XSS, el sistema relanza el payload en un navegador headless y verifica que efectivamente se ha disparado un alert. Si afirma haber descubierto una credencial válida, se prueba contra el endpoint correspondiente para confirmar que el login funciona. La idea es no fiarse de la interpretación del modelo y exigir una prueba observable del hallazgo.
Ahora bien, no todas las vulnerabilidades son tan sencillas de validar. Una vulnerabilidad relacionada con la lógica de negocio, o con un control de autorización, puede admitir interpretaciones que, en ocasiones, ni siquiera para un humano son evidentes a primera vista, y dependen del contexto del producto, de la intención del flujo o de qué se considera un acceso legítimo. En estos casos es donde el HITL vuelve a ser clave: el humano es quien decide qué hallazgos del agente se promueven a vulnerabilidades confirmadas, qué se descarta, y qué se queda en el limbo de hipótesis pendientes de revisión más profunda. Sin este filtro, el reporte final está condenado a mezclar hallazgos reales con ruido, y eso, en el peor caso, es peor que no haber detectado nada: hacer perder tiempo a un equipo de remediación con un falso positivo destruye la credibilidad del trabajo entero.
Casi todas las arquitecturas con orquestador comparten una limitación que un paper reciente identificó con claridad [7]: todas enfrentan con dificultad una pregunta importante, que es “¿merece la pena seguir por aquí?”. Tienen estructura, ya sea en forma de árboles, grafos, máquinas de estados o memoria, pero no tienen métricas de dificultad ni mecanismos sólidos para decidir cuándo abandonar una vía y probar otra. El resultado es que se atascan iterando sobre la misma aproximación cuando un humano ya habría pivotado.
Las arquitecturas más recientes empiezan a incorporar mecanismos para evaluar la dificultad de cada subtarea y para guiar la exploración de forma más inteligente, equilibrando la profundidad en la vía actual con la apertura a vías alternativas cuando la actual no avanza. No es magia, pero indica que el problema está identificado y hay un camino de mejora claro.
Ningún enfoque domina a los demás. Una recomendación pragmática, condensada:
Para uso personal recurrente sin presupuesto industrial, probablemente la opción más sostenible sea una arquitectura que combine los enfoques 5 y 6: un copiloto HITL apoyado en un agente de código con skills curados, ya sea Claude Code, Codex, Cursor, OpenCode o similares, según el caso. Esa combinación permite mantener continuidad y memoria entre sesiones, aprovechar los mecanismos de control que ya traen los agentes de código modernos, y conservar el criterio humano en los puntos donde realmente aporta valor.
Para tareas específicas y bien acotadas, como fuzzing creativo, generación de payloads contextuales, análisis de un binario o redacción de POCs, el modo agéntico básico con tools puntuales rinde, sobre todo si combinas la verificación determinista. Los servidores MCP de pentesting y los frameworks de subagentes encajan aquí.
Para pentest completo y autónomo, la respuesta práctica sigue siendo cautelosa. En pentest reales, a día de hoy en 2026, este enfoque rara vez compensa para un pentester individual que busque una solución para su día a día sin asumir unos costes elevados tanto económicos, como de ingeniería y de revisión manual de resultados. La mayoría de herramientas que se venden hoy como “pentest autónomo”, salvo excepciones comerciales que resuenan en la cabeza de todos (y que aún no se libran de revisión y filtrado manual), están todavía bastante por debajo del nivel que prometen.
Por encima de cualquier recomendación concreta, queda una idea más general. A pesar de las limitaciones y los retos que hemos ido describiendo, escogiendo una buena arquitectura para cada caso de uso, la IA puede aportar un valor interesante en el día a día del pentester. Y conforme los modelos siguen evolucionando en tareas de código y pentesting, ese valor no hace más que crecer. La pregunta para los próximos años no es tanto si merece la pena integrar IA en el flujo de trabajo, sino cuándo y cómo hacerlo para sacarle partido sin perder el control sobre lo que realmente está pasando.
En Kaptor Security hemos desarrollado herramientas que abordan todos los enfoques vistos anteriormente, y seguimos evolucionando para disponer de una infraestructura interna que mejore nuestro desempeño en cada engagement. Y si tu organización está integrando IA en sus procesos y quieres que apliquemos nuestros análisis manuales y guiados por IA para verificar si lo estás haciendo de forma segura, no dudes en contactarnos.