Por qué DevSecOps se convierte en el nuevo cuello de botella en la era del código por IA
Explica cómo el código generado por IA desplaza el cuello de botella de la ingeniería de software, pasando de escribir código a verificarlo, lo que convierte al DevSecOps automatizado en la capa crítica de confianza.
Fuentes: As AI Is Making Code Cheap. DevSecOps Is About to Become Much More Valuable
El software de desarrollo se vuelve drásticamente más barato, por lo que verificar dicho software adquiere una importancia aún mayor. Más código generado significa más áreas que probar. Más dependencias incorporadas implican mayor exposición a través de la cadena de suministro. Más aplicaciones desplegadas requieren más infraestructura para gestionarlas. Más lanzamientos significan más cambios que llegan a la producción. Y más código creado por IA plantea más preguntas sobre su origen, si es seguro, si cumple con los requisitos y quién es responsable de él. Por lo tanto, el próximo punto de inflexión real en la ingeniería de software podría no ser el código asistido por IA, sino DevSecOps impulsado por IA: la capa automatizada de confianza que se interponga entre el código generado por IA y los sistemas en producción.En resumen: Durante décadas, una de las partes más costosas de desarrollar software fue la propia tarea de escribirlo. Los ingenieros tenían que transformar los requisitos en arquitectura, generar miles de líneas de código, solucionar errores, escribir pruebas, conectar los sistemas y, finalmente, poner todo en funcionamiento. La IA generativa está cambiando por completo esta dinámica. Hoy en día, un desarrollador puede simplemente describir lo que necesita en lenguaje sencillo, y un agente de programación basado en IA producirá una gran parte de la implementación real: APIs, consultas SQL, conjuntos de pruebas, infraestructura como código, documentación, scripts de migración e, incluso, aplicaciones completas. Esto ya no es un experimento marginal. La investigación DORA de Google de 2025 reveló que el 90 % de los profesionales tecnológicos encuestados ya utilizaban la IA en su trabajo diario, y más del 80 % afirmó que esto los hacía más productivos. Pero hay un detalle importante a considerar: una vez creado
La dinámica actual: la IA está atacando el cuello de botella en la programación
El flujo clásico de ingeniería de software generalmente se ha presentado de la siguiente manera:
Requisitos → Diseño → Código → Pruebas → Seguridad → Despliegue → Operación
Durante la mayor parte de esa historia, la redacción del propio código consumía la mayor parte del esfuerzo.
Crear una nueva API a mano podía llevar fácilmente varios días a un desarrollador.
Ahora, en cambio, un desarrollador puede instruir a un agente de IA siguiendo estas pautas:
"Crea una API REST para la incorporación de nuevos clientes en Python. Incluye validación de entradas, una capa de persistencia, autenticación, pruebas unitarias, un Dockerfile y manifiestos de despliegue."
El agente puede completar una gran parte de ese trabajo en cuestión de minutos.
Eso representa un cambio fundamental en la economía de desarrollo de software.
El costo para crear una función adicional, un servicio más o una aplicación nueva sigue disminuyendo.
El alcance de la IA ya no se limita a completar automáticamente código: ahora se extiende hacia comportamientos basados en agentes, como analizar repositorios completos, editar múltiples archivos, ejecutar conjuntos de pruebas, corregir los problemas y abrir solicitudes de integración por sí sola.
Gartner define esta tendencia como ingeniería de software nativa de IA: un modelo en el que la IA está integrada en todo el ciclo de vida del desarrollo, en lugar de limitarse a ayudar con fragmentos de código. La empresa proyecta que para 2028, el 90 % de los ingenieros empresariales dependerá de asistentes de código basados en IA.
No obstante, escribir código más rápido no se traduce automáticamente en lanzar software con mayor rapidez.
Esa brecha es la parte importante.
Estamos desplazando el cuello de botella
Imagínese una organización de ingeniería que antes lanzaba:
100 cambios en el software cada semana.
Sus pipelines de pruebas, verificaciones de seguridad e infraestructura de despliegue estaban todos diseñados para manejar aproximadamente esa carga.
Ahora introducimos agentes de IA en la ecuación.
Los desarrolladores avanzan de repente mucho más rápido, y la cantidad de resultados semanales aumenta a:
300 cambios en el software.
Eso representa un salto enorme en la capacidad de programación bruta.
Pero ahora:
Los 300 cambios requieren revisión de código.
Los 300 cambios requieren pruebas.
Los 300 cambios necesitan una verificación de seguridad.
Los 300 cambios podrían introducir nuevas dependencias.
Los 300 cambios deben ser revisados en relación con las políticas establecidas.
Los 300 cambios requieren una decisión sobre su despliegue.
Y todo eso acaba sumándose a más software en ejecución que debe ser monitoreado en producción.
La restricción no ha desaparecido; solo se ha trasladado.
La antigua pregunta era:
¿Podemos desarrollar software lo suficientemente rápido?
La nueva pregunta es:
¿Podemos validar y ejecutar software de manera segura lo suficientemente rápido?
DORA describe el efecto de la IA como el de un amplificador: amplifica cualquier práctica de ingeniería que ya exista, sea buena o mala. Sus hallazgos sugieren que la IA puede acelerar la entrega mientras, al mismo tiempo, revela defectos en sistemas que no estaban diseñados para soportar tal velocidad.
Esa redefinición es de gran importancia.
La nueva ecuación de ingeniería de software
En términos sencillos, el patrón que se está formando es más o menos este: la adopción de la IA provoca un aumento en la generación de código, lo que a su vez incrementa el número de cambios que pasan por el proceso, lo cual exige mucha más validación; esto lleva a los equipos a recurrir más a la automatización, lo que finalmente impulsa a las organizaciones a invertir más en ingeniería de plataformas.
O, resumido en una sola frase:
Escribir código se vuelve más económico. Confiar en él es lo que realmente tiene valor.
Esa es la razón principal por la cual DevSecOps está destinado a ganar importancia a medida que el desarrollo asistido por IA se convierte en la norma, en lugar de quedar en segundo plano.
¿Qué es exactamente DevSecOps?
Es fácil reducir DevSecOps a “instalar un escáner de seguridad en tu pipeline CI/CD”, pero eso subestima lo que realmente abarca.
DevSecOps es mucho más amplio que eso.
En esencia, fusiona:
Desarrollo + Seguridad + Operaciones
en un único pipeline de entrega continuo.
Imagínalo como el mecanismo que decide si algo creado por un desarrollador —o, cada vez más, generado por un agente de IA— está realmente preparado para ejecutarse en producción.
Un pipeline completo de DevSecOps suele incluir:
Control de código fuente
Código de seguimiento, ramas, commits, solicitudes de integración y el historial a lo largo del tiempo.
Calidad del código
Analizador de estilo, análisis estático, verificaciones arquitectónicas y puntuación de mantenibilidad.
SAST
Pruebas de seguridad de aplicaciones estáticas que escanean directamente el código fuente en busca de defectos de seguridad.
Detección de secretos
Escaneo en busca de contraseñas, claves API, certificados o tokens que se hayan cometido accidentalmente en el repositorio.
SCA
Análisis de la composición del software que identifica dependencias de terceros riesgosas o vulnerables.
SBOM
Un inventario de componentes de software que cataloga los componentes reales incluidos en una aplicación.
Seguridad de IaC
Escáneres que examinan archivos Terraform, CloudFormation, manifiestos de Kubernetes y código de infraestructura similar.
Seguridad de contenedores
Verificación de imágenes de contenedor en busca de paquetes del sistema operativo vulnerables, bibliotecas desactualizadas y configuraciones incorrectas.
Pruebas
Pruebas unitarias, de integración, de regresión, API, de rendimiento y, cada vez más, pruebas generadas por IA que confirman que el comportamiento es correcto.
Políticas y cumplimiento
Reglas específicas para empresas que verifican si el software cumple con los estándares organizacionales, regulatorios y arquitectónicos.
CI/CD
Una vez aprobado, el software se desarrolla, se empaqueta y se distribuye por los diferentes entornos.
Despliegue
Estrategias de implementación como los lanzamientos tipo canario, despliegues azul/verde y flags de funcionalidades determinan cómo el código llega a producción.
Seguridad en tiempo de ejecución y observabilidad
Las aplicaciones en funcionamiento se monitorean continuamente en busca de vulnerabilidades, ataques, caídas, comportamientos inusuales y disminuciones en el rendimiento.
Todo este conjunto de herramientas se vuelve aún más crucial a medida que las máquinas asumen una mayor parte del trabajo de programación real.
La IA también transforma DevSecOps
Existe otra dimensión de este cambio que merece ser analizada.
DevSecOps no solo se encargará de un volumen mayor de código escrito por IA.
DevSecOps en sí mismo se está volviendo impulsado por IA.
En la actualidad, un escáner típico podría señalar algo como:
Se ha detectado una vulnerabilidad crítica en la dependencia X.
Una versión de ese mismo sistema impulsada por IA puede ir más allá:
Se ha detectado una vulnerabilidad crítica. Aquí está la razón por la que es importante. Aquí está el camino del código afectado. Aquí está la versión recomendada. He generado la corrección. He ejecutado las pruebas de regresión. Aquí está la solicitud de integración.
Eso representa una forma completamente diferente de operar.
De la detección a la remediación autónoma
Mire cómo esta capacidad tiende a evolucionar por etapas.
Generación 1: Detección
La herramienta alerta a un humano:
“Existe una vulnerabilidad.”
Luego, el ingeniero se dedica a investigarla.
Generación 2: Recomendación
La herramienta va más allá:
“Existe una vulnerabilidad, y aquí está cómo solucionarla.”
El ingeniero aplica la solución sugerida.
Generación 3: Remediación
La herramienta da otro paso:
“Existe una vulnerabilidad. Ya he escrito la solución y abierto una solicitud de integración.”
La tarea del ingeniero se convierte en revisarla.
Generación 4: DevSecOps autónomo
Con el tiempo, para los cambios con un riesgo lo suficientemente bajo, toda la cadena:
Detectar → Entender → Corregir → Probar → Validar → Desplegar → Monitorear
puede ejecutarse en gran medida sin intervención humana.
En lugar de realizar cada paso manualmente, las personas optan por establecer políticas, gestionar excepciones y supervisar el sistema en su conjunto.
La cadena de suministro de software se vuelve crítica
Existe una segunda razón por la cual esta transición es tan importante.
El software moderno rara vez se desarrolla completamente desde cero. En su lugar, se compone de muchas fuentes externas: bibliotecas extraídas de registros de código abierto, APIs de terceros, imágenes de contenedor preconstruidas, marcos de aplicaciones, servicios en la nube gestionados, módulos de infraestructura reutilizables y, ahora, resultados generados directamente por herramientas de IA.
La IA acelera enormemente este proceso de ensamblaje.
La investigación de Sonatype para 2026 sobre las cadenas de suministro de software describe que el ecosistema se acerca a una escala máquina, señalando la creación automática de versiones, la expansión de los gráficos de dependencias y agentes de IA que hacen que el origen y la confiabilidad sean más importantes que nunca.
Como resultado, las organizaciones necesitan cada vez más respuestas a preguntas como:
¿De dónde proviene este código?
¿Qué IA lo generó?
¿Qué versión del modelo lo creó?
¿Qué dependencias incorporó?
¿Esas dependencias fueron revisadas y aprobadas?
¿Qué pruebas de seguridad se realizaron en él?
¿Qué políticas se aplicaron?
¿Quién aprobó el despliegue?
¿Qué está realmente en ejecución en producción en este momento?
Eso lleva a DevSecOps mucho más allá de la simple automatización.
Se convierte en un sistema de confianza a nivel empresarial para el software.
La rendición de cuentas de la IA se convierte en un nuevo requisito
Esta preocupación ya está surgiendo en encuestas del sector.
Una encuesta de GitLab realizada en 2026 reveló que el 80% de los encuestados indicó que sus organizaciones habían implementado herramientas de IA más rápido de lo que habían desarrollado políticas de gobernanza para ello, y el 92% señaló enfrentar dificultades de gobernanza relacionadas específicamente con código generado por IA.
Imagínese a un auditor preguntando:
"¿Por qué este fragmento de código accede a los datos financieros del cliente?"
En el pasado, bastaba con nombrar al desarrollador responsable.
En un flujo de trabajo de desarrollo basado en agentes, la respuesta honesta podría ser en su lugar:
“Un agente de programación basado en IA lo creó mientras trabajaba en la función #4821.”
Eso plantea todo un nuevo conjunto de cuestiones relacionadas con la gobernanza.
¿Qué comando desencadenó su creación?
¿A qué contexto tuvo acceso?
¿Incorporó alguna nueva dependencia?
¿Esa dependencia estaba autorizada para su uso?
¿Qué pruebas se ejecutaron realmente?
¿Alguien revisó el cambio antes de la fusión?
¿Qué agente de seguridad de IA, si es que hubo alguno, lo evaluó?
En resumen, la procedencia de la IA se está convirtiendo en un nuevo elemento obligatorio dentro de la cadena de suministro de software.
El auge de las plataformas AI DevSecOps
Hoy en día, las empresas suelen utilizar una mezcla de herramientas desconectadas, algo como:
Desarrollador → GitHub → Jenkins → SonarQube → Snyk → Artifactory → Kubernetes → Datadog → ServiceNow
Cada herramienta aborda una parte específica del flujo de trabajo.
La IA hace que esta fragmentación sea mucho más costosa, ya que los agentes necesitan tener visibilidad de todo el ciclo de vida para ser útiles.
Un agente de IA que soluciona un incidente en producción podría necesitar acceso a:
- El requisito original
- Código fuente
- Historial de commits
- Resultados de pruebas
- Datos sobre vulnerabilidades
- Historial de despliegues
- Configuración de la infraestructura
- Registros en tiempo de ejecución
- Telemetría de producción
- Registros de incidentes anteriores
Esa necesidad está impulsando al mercado hacia plataformas de ingeniería unificadas.
Gartner ya incluye la ingeniería de plataformas y la ingeniería de plataformas habilitada con GenAI entre las tendencias clave en ingeniería de software, proyectando que para 2027 el 70% de las organizaciones que cuentan con equipos especializados en plataformas habrá integrado funciones de GenAI en sus plataformas internas para desarrolladores.
DORA plantea un punto relacionado: la calidad de una plataforma determina en gran medida si la adopción de la IA realmente mejora el rendimiento organizacional, o si simplemente genera “desorden posterior”.
Dónde se traslada el valor
Este cambio tiene consecuencias importantes para toda la industria tecnológica.
Durante la primera ola de entusiasmo por la IA generativa, la mayor parte de la atención se centró en una pregunta:
¿Cuál es el mejor asistente de programación?
Esa pregunta sigue siendo relevante.
Pero junto a ella está surgiendo una pregunta aún más importante para las empresas:
¿Quién controla el proceso que va desde una idea generada por IA hasta un software de producción fiable?
Ese proceso es donde ahora se concentra un valor enorme. Considere las capas involucradas:
Programación con IA
Herramientas como Copilot, Claude Code, Cursor y sus competidores.
↓
Fuente y colaboración
Plataformas como GitHub, GitLab y Bitbucket.
↓
Seguridad
SAST, SCA, escaneo de secretos, seguridad de contenedores y seguridad de la cadena de suministro.
↓
Gestión de artefactos
Paquetes, contenedores y registros de procedencia.
↓
CI/CD
Compilación, pruebas e implementación automatizadas.
↓
Plataformas en la nube
Infraestructura y entornos de ejecución.
↓
Observabilidad
Registros, métricas, trazas, incidentes e información sobre el funcionamiento en producción.
↓
Gobernanza
Políticas, aprobaciones, registros de auditoría y documentos de cumplimiento.
Cualquier plataforma que logre unificar estos elementos se volverá extraordinariamente importante desde el punto de vista estratégico.
El futuro: los desarrolladores se convierten en orquestadores
Nada de esto implica que el rol del desarrollador desaparezca.
Lo que cambia es lo que implica realmente el trabajo día a día.
La mayoría de los desarrolladores actualmente pasan la mayor parte de su tiempo escribiendo la lógica de implementación.
En el futuro, esa tarea se desplazará hacia el papel de orquestador de sistemas inteligentes.
En lugar de decirle a la máquina:
Escribe esta función.
el ingeniero dirá con más frecuencia:
Crea esta capacidad.
La IA se encargará de generar la implementación.
La atención del humano se dirige a evaluar las decisiones arquitectónicas, las reglas de negocio y la exposición al riesgo.
Los agentes de seguridad buscan puntos débiles.
Los agentes de pruebas confirman que el comportamiento es correcto.
Los agentes de despliegue se encargan de los mecanismos de implementación.
Los agentes de observabilidad vigilan una vez que el sistema está en funcionamiento en producción.
Cada vez más, la tarea de las personas consiste en supervisar el sistema en su conjunto en lugar de armarlo pieza por pieza.
Gartner ha hecho una predicción similar, describiendo cómo los desarrolladores se orientan hacia la orquestación, la definición de problemas, el diseño de sistemas y la verificación de que los resultados generados por la IA satisfacen realmente las expectativas de calidad.
También cambian los ingenieros DevSecOps
La función de DevSecOps evoluciona en una dirección similar.
Tradicionalmente, este trabajo giraba en torno a:
- Escribir pipelines
- Mantener Jenkins
- Configurar escáneres
Cada vez implica cosas como:
- Diseño de las plataformas que entregan software de principio a fin
- Establecimiento de las normas en las que depende toda una organización
- Redacción de las reglas de seguridad que deben seguir los agentes
- Vigilancia de lo que pueden hacer los agentes de codificación autónomos
- Diseño de sistemas que resuelven problemas automáticamente en lugar de esperar a un humano
- Rastreo del origen real de cada componente de software
- Creación de plantillas compartidas que los equipos pueden reutilizar en lugar de empezar desde cero
- Cuantificación del riesgo de ingeniería que asume la organización
- Mantenimiento de los sistemas de entrega autónoma para que funcionen de manera fiable
Dicho de otra forma:
El trabajo de DevSecOps deja de centrarse en mantener activos los pipelines y pasa a consistir en crear la capa de control que regula el software generado por IA.
Cambios en la seguridad: de guardián a barrera
En la mayoría de las organizaciones actuales, la seguridad funciona como un punto de control.
El equipo de desarrollo termina algo.
La seguridad lo revisa.
Aparece un problema.
El equipo de desarrollo lo corrige.
La seguridad lo verifica nuevamente.
Ese ir y venir se vuelve impráctico cuando la IA acelera el desarrollo mucho más de lo que solía ser.
El modelo que ocupa su lugar se parece más a esto:
Política → Automatización → Aplicación continua
Los equipos de seguridad escriben las reglas una sola vez.
Luego la plataforma aplica esas reglas sin cesar, sin esperar que una persona dé su aprobación cada vez.
Así es como funciona todo esto.
Regla: Ninguna API expuesta a Internet puede omitir la autenticación.
Un agente de IA envía una API que carece de esa verificación.
La plataforma DevSecOps lo detecta de inmediato.
El despliegue se bloquea automáticamente.
Al agente de programación se le indica con exactitud el motivo.
El agente de programación corrige la API.
Se vuelven a ejecutar las pruebas.
La regla de seguridad se cumple ahora.
El despliegue continúa.
Ningún miembro del equipo de seguridad revisó esto manualmente.
Aun así, la política se mantuvo en cada etapa del proceso.
Ese es el verdadero beneficio de DevSecOps impulsado por la IA.
Por qué las empresas pueden invertir más en DevSecOps, no menos
Es fácil suponer que la IA permitirá a las empresas arreglárselas con menos herramientas y menor gasto en infraestructura de ingeniería.
En las partes críticas del stack, lo opuesto es más probable.
La IA permite a las organizaciones crear mucho más software que antes.
Pero cada aplicación adicional que se lanza también conlleva una serie de consecuencias: otra API por exponer, otro contenedor por ejecutar, otro conjunto de dependencias por rastrear, más recursos en la nube por provisionar, otra ronda de análisis de seguridad, una implementación más por gestionar, más datos telemétricos por analizar, vulnerabilidades nuevas por corregir y pruebas adicionales de cumplimiento que deben recopilarse y almacenarse.
En resumen, más software en producción simplemente significa más de todo aquello que hay que supervisar, verificar y mantener confiable.
Los estudios anteriores de DevSecOps realizados por GitLab ya revelaron que los profesionales de la seguridad temían que el código generado por IA aumentara su carga de trabajo, y su investigación para 2026 señala lo que denomina un “paradoja de la eficiencia de la IA”, en la cual una generación más rápida de código combinada con herramientas desconectadas puede crear nuevos puntos críticos posteriormente en el proceso.
Por lo tanto, la perspectiva económica pasa de:
Pagar a las personas principalmente para que generen código
a:
Pagar por plataformas que puedan gestionar de forma segura un volumen masivo de resultados de software.
Un ejemplo sencillo
Aquí hay una ilustración concreta.
Imaginemos que un banco necesita una nueva función:
Permitir a los clientes congelar sus tarjetas de crédito desde la aplicación móvil.
Ayer
Un gerente de producto redacta los requisitos.
Un desarrollador diseña la API.
Ese desarrollador escribe el código.
Un colega lo revisa.
El equipo de QA crea un conjunto de pruebas.
El departamento de seguridad realiza sus escaneos.
DevOps organiza todo el proceso.
El equipo de operaciones se encarga del despliegue.
Todo esto puede tardar días o semanas en completarse.
Mañana
En cambio, un gerente de producto escribe:
"Permitir que los clientes autenticados congelen y descongelen una tarjeta, registren cada acción con fines de auditoría y notifiquen al cliente cuando esto ocurre."
Un agente de ingeniería toma ese requisito y lo lleva a cabo.
Esto genera:
- API
- Cambios en la base de datos
- Lógica empresarial
- Pruebas unitarias
- Pruebas de API
- Cambios en la infraestructura
- Documentación
Esto puede tomar solo unos minutos.
Ahora interviene la plataforma AI DevSecOps.
Detecta que la IA omitió una verificación de autorización obligatoria en el nuevo endpoint.
Agente de seguridad: BLOQUEAR.
También descubre que una biblioteca de código abierto recién incorporada presenta una vulnerabilidad crítica conocida.
Política de cadena de suministro: BLOQUEAR.
El agente de codificación reemplaza esa dependencia por otra más segura.
Se vuelven a ejecutar las pruebas.
Agente de pruebas: APROBADO.
La plataforma confirma que el cifrado, el registro de actividades y la autenticación están todos implementados.
Políticas de cumplimiento: APROBADO.
La aplicación se envía a un entorno de pruebas.
Se ejecutan transacciones sintéticas contra ella para simular un uso real.
Validación en tiempo de ejecución: APROBADO.
Un despliegue tipo canario envía una pequeña parte, digamos el 5%, del tráfico real a la nueva versión.
La capacidad de observación no muestra nada inusual en las tasas de error.
El tráfico se incrementa gradualmente hasta llegar a todos.
La función ya está activa.
Toda la secuencia deja un registro de auditoría completo:
Requisito → Agente de IA → Código → Dependencias → Pruebas → Decisiones de seguridad → Aprobaciones → Despliegue → Evidencia en tiempo de ejecución
Eso es AI DevSecOps en acción.
Y aquí está la parte interesante.
Generar el código fue en realidad el paso más fácil.
Lo valioso era la infraestructura capaz de responder con confianza:
¿Está este software realmente listo para entrar en producción?
El cambio más importante
Durante mucho tiempo, las conversaciones sobre la IA en la ingeniería de software se centraron principalmente en una cosa: el resultado del desarrollador.
¿Hasta qué punto puede la IA hacer que las personas que escriben código sean más rápidas?
Esa pregunta comienza a parecer demasiado limitada.
Una pregunta más amplia merece mayor atención:
¿Qué sucede una vez que la producción de software deja de ser un recurso escaso?
Cuando el código sea abundante, lo que realmente necesitan las organizaciones es una forma de establecer confianza a la misma velocidad con la que se escribe el código.
Eso implica pruebas.
Seguridad.
Gestión de la cadena de suministro de software.
Gobernanza.
Aplicación automática de políticas.
Automatización del despliegue.
Vigilancia de los sistemas en producción.
Rastreo del origen real del trabajo generado por IA.
Y, cada vez más, solución de problemas sin esperar a una persona.
Juntos, estos elementos conforman la próxima generación de DevSecOps.
La fase inicial de la IA en la ingeniería de software se centró principalmente en ayudar a las personas a escribir código más rápido.
La fase siguiente consiste en permitir que las personas y los agentes de IA gestionen juntos fábricas completas de software, de forma segura.
Visto de esa manera, DevSecOps no es una función que se ejecuta después del desarrollo para limpiar las cosas posteriormente.
DevSecOps se convierte en el plano de control sobre el cual funciona toda la fábrica de software impulsada por IA.
Lecturas relacionadas
- Bases de datos vectoriales explicadas: cómo las máquinas buscan por significado — Aprenda cómo las bases de datos vectoriales convierten texto en representaciones numéricas para posibilitar búsquedas semánticas, y cómo difieren de las bases de datos tradicionales.