Puedes pedirle a una IA que construya una aplicación y obtener rápidamente formularios, páginas y una API que parece funcionar. Pero ¿qué datos envía esa API? ¿El empleado recibe solo la información necesaria o llega a su navegador el perfil completo del usuario?
Esta guía sobre DTO con IA parte de una situación sencilla: un gerente y un empleado utilizan la misma aplicación, pero necesitan información diferente. Entenderás qué hace un DTO y, sobre todo, qué pedirle exactamente a Codex, Claude o Grok para obtener una implementación adecuada para tu proyecto.
No necesitas memorizar definiciones complicadas. Necesitas poder describir quién solicita la información, qué puede recibir y cómo comprobarás el resultado.
DTO con IA: qué debes entender antes de escribir el prompt
¿Qué significa DTO, explicado de forma sencilla?
DTO significa Data Transfer Object: un objeto utilizado para transferir datos entre partes de un sistema. En una API puedes usarlo para describir la estructura de los datos recibidos o enviados. Martin Fowler explica este patrón como un objeto que transporta datos y puede transformarse en un formato que se transmite por la red.
Imagina un expediente interno y dos extractos preparados a partir de él. El expediente es la fuente de información. Un extracto contiene tres campos y el otro, cinco. No creas dos usuarios nuevos ni dos cuentas. Preparas dos representaciones de la información de un mismo usuario.
Un DTO puede implementarse como una clase, un record u otra estructura adecuada para el lenguaje. La forma concreta depende del proyecto. Para empezar, lo importante es la lista de campos que defines.
La entidad, el DTO y la respuesta de la API
En nuestro ejemplo, la entidad Usuario es el modelo interno con el que trabaja la aplicación. El DTO describe los datos seleccionados para un intercambio concreto. La respuesta de la API es lo que recibe realmente el cliente, muchas veces en formato JSON.
Estos elementos están relacionados, pero no son idénticos. El DTO debe utilizarse realmente al construir la respuesta: la simple existencia de una clase llamada UserDTO no cambia automáticamente los datos que envía la API.
Un ejemplo sencillo: un usuario, dos respuestas
¿Qué puede ver el empleado y qué puede ver el gerente?
Supongamos que desarrollamos una aplicación interna. Establecemos esta regla ficticia: el empleado puede consultar su propio perfil y el gerente puede consultar los perfiles de los miembros de su equipo.
| Campo | DTO del empleado | DTO del gerente |
|---|---|---|
| ID | Sí | Sí |
| Nombre | Sí | Sí |
| Dirección | Sí, en este ejemplo | Sí, en este ejemplo |
| Correo profesional | No | Sí |
| Departamento | No | Sí |
| Hash de la contraseña | Nunca | Nunca |
| Token para restablecer la contraseña | Nunca | Nunca |
Incluimos la dirección para que el ejemplo resulte fácil de seguir. En tu aplicación, añádela solo si la función la necesita y la política de acceso lo permite. Tener el rol de gerente no concede, por definición, acceso a todos los datos de una persona.
¿Por qué el DTO no sustituye a los permisos?
La autorización determina si una persona puede acceder a un recurso concreto y a determinados campos. El DTO define la estructura de los datos que la aplicación transmite después de aplicar esas reglas.
Un DTO con tres campos puede revelar información si se envía a la persona equivocada. Por ejemplo, un empleado no debe poder leer el perfil de otro empleado simplemente cambiando el ID de la dirección. OWASP describe por separado este problema de autorización a nivel de objeto.
Ocultar un campo en la interfaz tampoco resuelve el problema. Si el servidor lo envía, puede leerse en la respuesta de la API. Las recomendaciones de OWASP sobre el acceso a propiedades de los objetos indican que hay que seleccionar explícitamente los datos adecuados para el destinatario.
Explica a la IA qué estás construyendo
Sustituye la petición vaga por una situación concreta
«Hazme unos DTO para usuarios» deja muchas decisiones sin definir. La IA no sabe si trabajas en un directorio público, un panel interno o una aplicación para varias organizaciones. El nombre de la clase tampoco indica quién debería poder ver las direcciones o los correos electrónicos.
Empieza por el objetivo de la función:
Trabajo en una aplicación interna para una empresa. Tenemos los roles de empleado y gerente. El empleado consulta su propio perfil. El gerente consulta los perfiles de los miembros de su equipo. Quiero respuestas de la API diferentes para estas situaciones, utilizando DTO o el mecanismo equivalente que ya exista en el proyecto.
Ahora la petición incluye un resultado observable. Además de un objeto de código, estás pidiendo un comportamiento concreto de la aplicación.
Aporta el contexto del proyecto
Con acceso al código o en una conversación sencilla
Si el asistente tiene acceso al proyecto, señala el módulo relevante y pídele que examine la implementación existente: el modelo del usuario, las rutas, la autorización y las pruebas de esa función. Si trabajas en un chat sin acceso a archivos, adjunta los fragmentos pertinentes con datos ficticios.
Puedes escribir:
Comprueba primero cómo se construyen las respuestas de la API y cómo se gestionan los permisos en este proyecto. Identifica los archivos relevantes y sigue las convenciones existentes. Si no tienes acceso al código, dime exactamente qué fragmentos debo facilitarte. No inventes la estructura de la aplicación.
La misma petición puede utilizarse en Codex, Claude o Grok. Lo que el asistente pueda ejecutar realmente depende del entorno y de las herramientas disponibles. Un ejemplo de código en un chat no significa que tu proyecto se haya modificado o probado.
Define exactamente los campos permitidos
Escribe la lista de campos que deben incluirse
«Oculta la información sensible» es demasiado impreciso. En un proyecto el correo puede ser público; en otro, solo visible para el equipo. Indica qué campos están aprobados para cada respuesta.
Para la respuesta destinada al empleado, incluye exactamente: id, nombre, direccion. Para la respuesta destinada al gerente, incluye exactamente: id, nombre, direccion, emailProfesional, departamento. Adapta los nombres a las convenciones del proyecto. No incluyas otras propiedades del modelo interno.
Una lista de inclusión ayuda a evitar una situación que suele pasarse por alto: más adelante añades un campo al modelo y aparece por accidente en la respuesta. En este ejemplo, el nuevo campo debe quedar fuera del contrato hasta que se apruebe explícitamente.
Pide un ejemplo del resultado
Antes de implementar, pide dos ejemplos con datos ficticios. Comprueba que la respuesta del empleado solo contiene los tres campos y la del gerente, únicamente los cinco. Si la IA añade automáticamente el salario, el teléfono u otros datos, corrige el contrato antes de continuar.
Un ejemplo pequeño aclara la conversación más que una explicación extensa sobre «datos completos».
Especifica las reglas de acceso
¿Quién solicita los datos y de quién son?
Son dos preguntas diferentes. En nuestro ejemplo, un empleado autenticado puede solicitar su propio perfil. Un gerente puede solicitar el perfil de un miembro de su equipo. Ser gerente no permite leer automáticamente los perfiles de cualquier equipo.
Añade al prompt:
Obtén la identidad y el rol del solicitante a partir del mecanismo de autenticación verificado de la aplicación. Comprueba el acceso al usuario solicitado. No concedas permisos basándote en un parámetro de rol recibido del cliente. Deniega el acceso cuando las reglas no permitan leer el perfil.
Dos endpoints pueden organizar la función con claridad, pero sus nombres no conceden permisos. Una ruta que contiene la palabra «gerente» sigue necesitando una comprobación de acceso en el servidor. Si la aplicación ya tiene una ruta adecuada, no es obligatorio crear otras dos.
Pide una implementación adecuada para el proyecto
¿Cómo llegan los datos al DTO?
La transformación de los datos internos en los campos de la respuesta suele llamarse mapeo. Por ejemplo, la aplicación lee el nombre del modelo y lo coloca en el campo correspondiente del DTO.
Puedes pedir dos métodos de mapeo claros, uno para cada contrato. Pero no conviertas ese detalle en una regla universal. Algunos proyectos ya utilizan mapeadores, serializadores u otros mecanismos para las respuestas. Lo importante es que la selección de campos sea explícita y verificable.
Implementa el mapeo explícito de los campos aprobados. Integra los DTO en las respuestas reales de la API y conserva la separación existente entre autorización, lógica de la aplicación y construcción de respuestas. Evita introducir bibliotecas o reestructuraciones que este cambio no necesite.
Separa la lectura de la modificación de datos
Un perfil devuelto por la API y un formulario enviado a la API no tienen necesariamente los mismos campos. Poder ver el departamento no significa poder modificarlo.
Si la función incluye editar el perfil, pide un contrato de entrada separado, con validación y autorización de los campos modificables. Si solo trabajas en la lectura, limita la tarea a las respuestas. Esta delimitación ayuda a la IA a no ampliar innecesariamente la implementación.
Pide comprobaciones que puedan demostrar el resultado
¿Qué deben demostrar las pruebas?
Para esta función, las pruebas útiles comprueban las respuestas y las reglas de acceso, además de la posibilidad de crear un DTO. Dale al asistente situaciones concretas:
- El empleado solicita su perfil y recibe exactamente los tres campos aprobados.
- El empleado solicita el perfil de otra persona y se le deniega el acceso.
- El gerente solicita el perfil de un miembro de su equipo y recibe exactamente los cinco campos aprobados.
- El gerente solicita un perfil ajeno a su equipo y se le deniega el acceso.
- Una solicitud sin autenticar no recibe datos del perfil.
- Cambiar un parámetro de rol en la solicitud no concede permisos adicionales.
- Los hashes de contraseñas, los tokens de restablecimiento y otros campos internos no aparecen en las respuestas.
Los códigos HTTP y el formato de los errores deben respetar el contrato del proyecto. No exijas un código concreto solo porque aparezca en un ejemplo si tu aplicación utiliza intencionadamente otro comportamiento.
Pide evidencias de las comprobaciones ejecutadas
Ejecuta las comprobaciones relevantes disponibles en el proyecto. Al terminar, indica qué comandos ejecutaste, qué resultados obtuviste y qué no pudiste verificar. Si solo escribiste pruebas sin ejecutarlas, dilo expresamente.
Una respuesta que dice «he añadido las pruebas» describe un cambio. El resultado de ejecutarlas aporta una evidencia adicional. Necesitas saber cuál de las dos cosas ha ocurrido.
Pide una explicación que puedas comprobar
¿Cómo evalúas el resultado sin ser experto?
Después de implementar, pide una explicación breve del recorrido de los datos: quién hace la solicitud, dónde se comprueban los permisos, dónde se eligen los campos y cómo se construye la respuesta. Pide también los archivos modificados y el motivo de cada cambio.
Explícame la implementación con un lenguaje sencillo. Muestra dónde se comprueba el acceso y dónde se seleccionan los campos devueltos. Presenta un ejemplo para cada rol e indica las pruebas que confirman el comportamiento. Señala cualquier supuesto de negocio que siga sin confirmarse.
Si la explicación no coincide con los ejemplos de respuesta, pide una revisión concreta. No necesitas entender cada instrucción del código para observar que el DTO del empleado contiene un campo que no has aprobado.
Prompt completo para Codex, Claude o Grok
Copia y adapta la petición
Sustituye las reglas ficticias por las reglas de tu aplicación. Si no has decidido quién puede ver un campo determinado, acláralo antes de pedir la implementación.
Quiero implementar respuestas de la API basadas en DTO para los perfiles de usuarios de la aplicación existente.
Contexto: tenemos los roles de empleado y gerente. El empleado solo puede consultar su propio perfil. El gerente puede consultar los perfiles de los miembros de su equipo. Estas son las reglas de la función que estamos construyendo.
Contrato del empleado: exactamente id, nombre, direccion. Contrato del gerente: exactamente id, nombre, direccion, emailProfesional, departamento. Utiliza los nombres equivalentes del proyecto. No deben devolverse contraseñas, hashes, tokens de restablecimiento ni otros datos internos.
Examina la implementación existente y sigue las convenciones del proyecto. Si no tienes acceso a los archivos, pide los fragmentos necesarios. Identifica la autenticación, la autorización, el modelo del usuario, la construcción de respuestas y las pruebas relevantes.
Comprueba en el servidor la identidad del solicitante, el acceso al perfil solicitado y los campos que puede recibir. No utilices un rol enviado por el cliente para conceder permisos. El DTO no sustituye a la autorización.
Construye explícitamente las respuestas aprobadas mediante DTO o el mecanismo equivalente existente. Intégralas en los endpoints reales. Un campo añadido posteriormente al modelo no debe aparecer automáticamente en la respuesta. Limita el cambio a esta función.
Comprueba mediante pruebas las respuestas para ambos roles, el acceso no autorizado a otros perfiles, las solicitudes sin autenticar, los intentos de cambiar el rol mediante la solicitud y la ausencia de campos internos. Respeta el formato de errores del proyecto.
Si tienes acceso de trabajo al proyecto, implementa la solución y ejecuta las comprobaciones relevantes. Si solo puedes ofrecer una propuesta, indícalo expresamente. Al terminar, presenta los archivos modificados, los ejemplos de respuesta, los resultados de las comprobaciones y los supuestos que requieren una decisión por mi parte.
¿Cómo continúas la conversación después del primer resultado?
Utiliza observaciones concretas: «En la respuesta del empleado también aparece el correo; elimínalo del contrato y comprueba la prueba correspondiente» resulta más útil que «está mal». Para una revisión, puedes pedir: «Sigue el recorrido real de la respuesta y comprueba si existe alguna vía que devuelva directamente el modelo interno».
La fórmula objetivo, contexto, reglas, ejemplos y comprobaciones también puede aplicarse a reservas, pedidos o facturas. El contexto y los criterios claros aparecen en la guía de OpenAI para trabajar con Codex, en las recomendaciones de Anthropic para Claude y en la guía de xAI para Grok. El prompt anterior es nuestro ejemplo de aplicación a los DTO.
Preguntas frecuentes sobre DTO e IA
¿Necesito saber programar para pedir DTO a una IA?
Puedes empezar definiendo los roles, los campos y los ejemplos de respuesta. Para evaluar la implementación, necesitas comprobaciones y alguien que pueda revisar el código cuando el cambio supere tu nivel de comprensión.
¿El DTO es una tabla nueva en la base de datos?
No. Crear un DTO no implica crear automáticamente una tabla. Describe datos que se transfieren. No pidas una migración de la base de datos solo porque necesites una respuesta de la API diferente.
¿Son obligatorios dos DTO para dos roles?
No. El ejemplo utiliza dos contratos para hacer visible la diferencia. En un proyecto real, los contratos pueden organizarse por función o caso de uso, y varios roles pueden compartir el mismo contrato cuando las reglas lo permiten.
¿El DTO protege por sí solo la información?
No. La selección de datos debe ir acompañada de autorización. Comprueba tanto quién puede recibir la respuesta como qué información contiene.
¿Puedo utilizar el mismo prompt en Codex, Claude y Grok?
Sí, los requisitos de negocio son los mismos. Adapta el contexto y la petición de ejecución al acceso real del asistente: una conversación, archivos adjuntos o un entorno conectado al proyecto.
¿Qué hago si la IA dice que la implementación está lista?
Pide los ejemplos de respuesta y los resultados de las comprobaciones ejecutadas. Compáralos con tus reglas. Un mensaje de confirmación no sustituye la verificación del comportamiento de la aplicación.
Empieza por los datos que quieres enviar
Para trabajar con más claridad con la IA, describe primero el resultado: quién solicita los datos, qué perfil puede consultar y qué campos puede recibir. Después pide la implementación y las evidencias de que respeta esas reglas.
Los DTO son un buen ejemplo de esta forma de trabajar: una idea técnica se vuelve más fácil de pedir cuando la conviertes en reglas concretas y resultados que puedes comprobar.