La IA agéntica llega al desarrollo de bases de datos: qué cambia cuando la IA puede ejecutar consultas de verdad

Durante los últimos años, el desarrollo de bases de datos asistido por IA ha seguido un modelo bastante cómodo. Un desarrollador describe un requisito. La IA genera SQL. El desarrollador lo lee, corrige lo que le parece incorrecto y decide si lo ejecuta.

Ese flujo de trabajo ha mantenido intacto un límite importante: la IA puede sugerir una acción, pero sigue siendo una persona quien decide si esta llega a la base de datos.

Sin embargo, con la IA agéntica, ese límite empieza a desaparecer. Hoy, los sistemas de IA pueden inspeccionar esquemas, ejecutar consultas, interpretar los resultados y decidir qué acción tomar a continuación. Según una encuesta reciente, el 62 % de las organizaciones ya está experimentando con agentes de IA, mientras que el 23 % afirmó haber ampliado el uso de un sistema agéntico en algún área de la empresa.

Por lo tanto, los equipos de bases de datos tienen que responder de inmediato a una cuestión de arquitectura. No se trata de si la IA puede ejecutar SQL. Puede hacerlo. La verdadera pregunta es qué cambia cuando un asistente deja de sugerir código y empieza a actuar sobre la base de datos, y hasta qué punto debe controlarse esa autonomía.

De las sugerencias a las acciones

Una sencilla decisión sobre la indexación muestra por qué importa ese cambio.

Un agente detecta una consulta lenta, consulta el esquema, concluye que un índice podría ayudar, lo crea, vuelve a ejecutar la carga de trabajo y comprueba el resultado.

Podría ejecutar algo tan corriente como lo siguiente:

CREATE INDEX IX_Orders_CustomerId
ON Orders(CustomerId);

Esa instrucción no tiene nada de extraordinario. Un asistente de IA podría haber sugerido exactamente lo mismo. La diferencia está en quién toma la decisión final.

Con un asistente, el desarrollador revisa la recomendación, la prueba y decide si la ejecuta. La IA aconseja, pero la persona actúa. En cambio, si un agente tiene permisos de ejecución, el sistema puede tomar esa decisión por sí mismo y seguir adelante sin esperar aprobación.

Si la decisión es acertada, el flujo de trabajo se agiliza. Pero los agentes no siempre tienen toda la información. Puede que no detecten dependencias de la aplicación, reglas de negocio, patrones de carga de trabajo, ventanas de mantenimiento u otro contexto que resulta evidente para quienes gestionan el sistema.

Por eso, un agente puede tomar una decisión que parezca razonable desde el punto de vista técnico y, aun así, ser equivocada para el entorno en el que actúa, dadas sus restricciones y requisitos específicos.

El peligro aumenta cuando las acciones empiezan a encadenarse. Una mala SELECT puede simplemente ejecutarse con lentitud. Una mala UPDATE puede bloquear una tabla grande entera o afectar a muchas más filas de las previstas. Un índice utilizado para una consulta quizá sea innecesario y, sin embargo, añada sobrecarga a otras consultas. Un cambio en el esquema puede romper algo que, sin saberlo, dependía de él, porque el agente quizá no disponga de todo el contexto operativo ni pueda probar todos los casos de uso posibles.

Así que el problema no es que los agentes sean incapaces de tomar buenas decisiones sobre bases de datos. A menudo sí pueden hacerlo. El problema es que, cuando se les permite actuar en función de esas decisiones, los equipos deben definir con mucha más claridad hasta dónde llega esa autoridad, qué contexto puede ver el agente, en qué momento debe intervenir una persona y quién sigue siendo responsable del resultado.

Gartner prevé que más del 40 % de los proyectos de IA agéntica se cancelarán antes de finales de 2027, en parte debido a controles de riesgo insuficientes. Para los equipos de bases de datos, la lección es bastante sencilla: los permisos de ejecución deben concederse después de establecer los controles, no antes.

¿Qué se puede delegar de forma segura?

Algunas tareas de bases de datos son mucho más seguras de delegar que otras.

El análisis de consultas es un buen ejemplo. Un agente puede inspeccionar estadísticas de consultas, obtener planes de ejecución y revisar índices y estructuras de tablas, además de sugerir posibles soluciones sin modificar los datos de producción.

Podría detectar una consulta como esta que recorre repetidamente una gran Orders tabla:

SELECT OrderId, OrderDate, Total
FROM Orders
WHERE CustomerId = @CustomerId
ORDER BY OrderDate DESC;

A partir de ahí, puede explicar el recorrido, sugerir un índice y generar el DDL. No necesita permiso para ejecutar CREATE INDEX para resultar útil.

Lo mismo se aplica a tareas como las siguientes:

• Describir planes de ejecución;
• Identificar índices que faltan o son innecesarios;
• Señalar SELECT * consultas o predicados no sargables;
• Revisar la inserción de operaciones de unión y filtros en capas inferiores;
• Revisar dependencias y esquemas;
• Resolver errores de SQL;
• Optimizar scripts SQL.

La división práctica es sencilla: dar al agente suficiente acceso para comprender el problema, pero no necesariamente el acceso necesario para modificar la base de datos. Una visibilidad amplia puede ser útil, pero conceder permisos de ejecución amplios es una decisión distinta.

Dónde sigue siendo importante el control humano

Algunas decisiones sobre bases de datos todavía requieren la intervención de una persona. Supongamos que un agente encuentra una AuditLog tabla con cientos de millones de filas y decide que deben eliminarse los registros antiguos:

DELETE FROM AuditLog
WHERE CreatedAt < DATEADD(year, -2, GETDATE());

El SQL puede ser perfectamente válido y, aun así, dar lugar a una decisión pésima.

Quizá la normativa exija conservar los datos durante siete años. Tal vez una aplicación dependa de esos registros. Puede que sea necesario eliminarlos por lotes para evitar que crezca el registro de transacciones. Quizá haya que archivar los registros antes de eliminarlos.

Ninguno de esos requisitos tiene por qué estar necesariamente definido en el esquema.

Esta es una de las limitaciones de tratar el trabajo con bases de datos como un problema de generación de código. Las bases de datos contienen estructuras técnicas, pero las decisiones relacionadas con ellas suelen ser decisiones empresariales expresadas mediante operaciones técnicas. La misma cautela debe aplicarse a operaciones como:

• DROP y destructivas ALTER sentencias;
• producción UPDATE y DELETE operaciones;
• migraciones de datos de gran volumen;
• cambios de roles y permisos;
• modificaciones de restricciones;
• cambios que afectan a la replicación o la disponibilidad;
• implementación de procedimientos almacenados que contienen lógica de negocio.

Una acción técnicamente correcta no es necesariamente una acción adecuada. Por tanto, la aprobación humana no debe considerarse una limitación molesta para la IA agéntica. En las operaciones con bases de datos de gran impacto, forma parte de la arquitectura.

Los agentes de IA también necesitan el mínimo privilegio

Un atajo que los equipos de bases de datos deberían evitar es permitir que un agente utilice las credenciales existentes de un desarrollador. Es fácil, pero le da al agente todos los accesos que ya tiene ese desarrollador.

El enfoque más seguro es el mismo que se utiliza para los usuarios y los servicios: el mínimo privilegio. Microsoft recomienda conceder únicamente los permisos necesarios para la tarea y supervisar la actividad privilegiada.

Por ejemplo, un agente de análisis del rendimiento podría necesitar:

CONNECT
SELECT
VIEW DATABASE STATE
VIEW DEFINITION

Probablemente no necesite:

ALTER ANY TABLE
CONTROL DATABASE
db_owner
sysadmin

Los distintos agentes también pueden tener identidades diferentes. Un agente de informes podría obtener SELECT acceso a unos pocos esquemas. Un agente de migración podría trabajar únicamente en desarrollo o preproducción. Un agente de producción podría tener permisos estrictamente delimitados y, aun así, necesitar aprobación antes de poder ejecutar operaciones.

OWASP recomienda el mismo patrón básico para los agentes de IA: separar los accesos de lectura y escritura, limitar las herramientas y los recursos, y exigir autorización explícita para las acciones sensibles.

La regla es sencilla: concede al agente los permisos que necesita para su trabajo, no los permisos de la persona que lo puso en marcha.

Incorpora a las personas al flujo de trabajo

Un modelo mejor para el trabajo agéntico con bases de datos es un flujo de trabajo controlado:

Observar → Analizar → Proponer → Revisar → Ejecutar → Validar → Registrar

Supongamos que un agente investiga un endpoint de API lento. Encuentra el SQL que hay detrás, comprueba el plan de ejecución y las estadísticas de las tablas, detecta un índice que probablemente falta y prepara un script de migración.

Ese script puede ejecutarse primero en preproducción. El agente vuelve a ejecutar la carga de trabajo, comprueba el resultado y prepara el cambio para producción.

Entonces se detiene.

Un desarrollador o un administrador de bases de datos revisa la migración, comprueba las dependencias y el impacto en el negocio, y la aprueba antes de que nada llegue a producción.

El agente todavía puede encargarse de gran parte del trabajo repetitivo. La responsabilidad final de los cambios de gran impacto sigue recayendo en las personas.

Los controles de transacciones pueden añadir otra capa de seguridad. Por ejemplo, los puntos de guardado de PostgreSQL permiten revertir parte de una transacción sin descartar todo lo que se hizo antes. Esto puede ayudar con cambios automatizados estrechamente delimitados, aunque la reversión no sustituye a los permisos adecuados ni a la aprobación.

Aquí también encajan de forma natural herramientas como dbForge AI Assistant. Puede utilizar el contexto del esquema para generar y explicar SQL, solucionar errores, comparar DDL, detectar índices ineficientes y preparar scripts de optimización, y mantiene el SQL resultante visible para que lo revise un desarrollador.

El objetivo es automatizar el trabajo rutinario y dejar las decisiones importantes en manos de las personas.

El verdadero objetivo es la autonomía controlada

La IA agéntica no tiene por qué implicar elegir entre «la IA solo hace sugerencias» y «la IA administra la base de datos». Hay mucho margen entre ambas opciones.

Los equipos pueden empezar con tareas de menor riesgo, como explicar SQL, revisar esquemas y realizar comprobaciones de solo lectura. A partir de ahí, los agentes pueden asumir gradualmente más trabajo en desarrollo y preproducción.

El acceso de escritura debería concederse mucho más adelante y con límites claros en cuanto a las filas afectadas, las transacciones, la reversión, la supervisión y las aprobaciones. Los cambios totalmente autónomos en producción deberían ser poco frecuentes.

Esto también coincide con las recomendaciones de Deloitte: empezar con flujos de trabajo de menor riesgo y datos no críticos, mantener a las personas informadas y reforzar la gobernanza a medida que los agentes adquieren más autonomía.

El objetivo no es la autonomía absoluta. Se trata de dar al agente suficiente libertad para ayudar, pero no más acceso del que necesita.

Conclusión: el desarrollo de bases de datos sigue requiriendo criterio

Los agentes de IA pueden reducir mucho el trabajo repetitivo en la ingeniería de bases de datos. Pueden observar las cargas de trabajo, examinar consultas, relacionar esquemas, planes, errores y datos de rendimiento, y actuar en función de lo que detectan.

Pero cuando un sistema de IA puede modificar el estado de la base de datos, el problema cambia. Los equipos necesitan reglas claras sobre identidad, permisos, límites de las transacciones, aprobaciones, observabilidad, reversión y registros de auditoría.

Por eso, aunque el 88 % de las organizaciones utilizaba IA en 2025, solo el 7 % afirmó que su uso se había extendido plenamente a toda la organización. El reto más difícil es conseguir que la IA sea lo bastante fiable como para operar a gran escala.

El desarrollo de bases de datos avanza en la misma dirección. El agente más útil no será el que tenga más libertad para actuar, sino aquel cuya autoridad se entienda y controle claramente.

La pregunta ya no es si la IA puede ejecutar tareas relacionadas con bases de datos, sino en cuáles deberíamos confiar en ella y con qué restricciones.