--- title: "¿Puede un agente de IA usar tu producto, o solo leer sobre él?" canonical: https://wavect.io/es/blog/can-an-ai-agent-use-your-product/ language: es description: "Qué hace falta para que un producto sea usable por agentes y no solo legible: identidad delegada, autorización a nivel de datos, idempotencia, semántica de errores, MCP y agent skills." image: "https://wavect.io/img/blog/headers/header_can-an-ai-agent-use-your-product.png" --- [**Volver**](/es/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/es/team/kevin-riedl/) [Kevin Riedl](/es/team/kevin-riedl/) https://linkedin.com/in/wsdt 8 min de lectura · 18 ago 2026 Última revisión 18 de agosto de 2026 [**Siguiente**](/es/blog/agent-readable-website-llms-txt-markdown-mirrors/) # ¿Puede un agente de IA usar tu producto, o solo leer sobre él? Resumen Ser legible para un agente y ser usable por uno son proyectos distintos, y la mayoría de los equipos solo ha hecho el primero. Legible significa que un asistente puede descargar, interpretar, citar y atribuirte. Usable significa que puede autenticarse como un usuario concreto, llamar a una herramienta, cambiar estado y ser rechazado cuando corresponde. Lo segundo es sobre todo un problema de autorización, identidad y semántica de errores más que de modelo, y su ritmo lo marca la precisión con la que puedes decir no, porque un error de legibilidad cuesta una cita mientras que uno de autorización cuesta un incidente. Una superficie de herramientas usable necesita cinco cosas: identidad delegada que exprese qué agente actúa por qué usuario y en qué alcance, autorización aplicada en la capa de datos y no en el prompt, claves de idempotencia porque los agentes reintentan ante timeouts que malinterpretan, mensajes de error que nombren el campo que falló para que el modelo se corrija en lugar de entrar en bucle, y descubrimiento mediante MCP y agent skills publicadas. MCP es el transporte y no el modelo de autorización; tratarlo como tal es el error habitual. Una secuencia defendible es herramientas de solo lectura, después un mapa publicado, después una escritura de bajo riesgo detrás de aprobación humana, y después ampliar solo donde el registro de auditoría muestre un comportamiento consistentemente correcto. Hoy nadie puede cuantificar los ingresos que llegan por agentes, así que el argumento para los primeros pasos se apoya en que son baratos y útiles para las integraciones humanas de todos modos. **Ser legible para un agente y ser usable por uno son proyectos distintos, y casi todos los equipos han hecho solo el primero.** Legible significa que un asistente puede resumirte y citarte. Usable significa que puede completar una tarea en tu producto en nombre de una persona concreta, y que puede ser detenido cuando corresponde. Lo segundo no es, en su mayor parte, un problema de modelo. Es un problema de autorización, identidad y semántica de errores, y por eso aterriza en ingeniería y no en marketing. ## Dos preguntas distintas | | Legible | Usable | | --- | --- | --- | | Qué hace el agente | Descarga, interpreta, cita, atribuye | Se autentica, llama, cambia estado, informa de vuelta | | Superficie | HTML, espejo en Markdown, llms.txt, JSON-LD | Herramientas con esquemas, identidad, permisos, auditoría | | Fallo | Estás ausente de la respuesta | Pasa algo que no debería haber pasado | | Coste de equivocarse | Atención perdida | Datos, dinero o confianza perdidos | Esa última fila es la razón de que la segunda columna lleve más tiempo. Un error de legibilidad te cuesta una cita. Un error de autorización te cuesta un incidente, así que el ritmo del trabajo lo marca la seguridad con la que puedes decir no. Si la primera columna aún no está hecha, empieza ahí. Nuestra [guía de webs legibles por agentes](/es/blog/agent-readable-website-llms-txt-markdown-mirrors/) lo cubre, y es una fracción del esfuerzo. ## Qué exige de verdad "usable" Una superficie de herramientas que un agente pueda operar necesita cinco cosas, y las interesantes no son la API. - **Identidad que no sea la del agente.** El agente actúa por un usuario o un inquilino. Si tus tokens no pueden expresar "este agente, en nombre de esta persona, para este alcance, hasta este momento", en la práctica cada llamada es una llamada de administrador. - **Autorización en la capa de datos.** Filtrar en el prompt no es control de acceso. El límite va donde se ejecuta la consulta, para que una instrucción persuasiva no pueda ensancharlo. - **Idempotencia.** Los agentes reintentan. Reintentan ante timeouts que malinterpretan y respuestas parciales que no entendieron. Toda llamada que cambie estado necesita una clave que convierta el segundo intento en una operación nula. - **Semántica de errores sobre la que un modelo pueda actuar.** Un 400 que dice "petición inválida" produce un bucle de reintentos. Uno que dice qué campo falló y qué forma esperaba produce una llamada corregida. Esto es documentación como superficie de control. - **Descubrimiento.** Algo tiene que decirle al agente que las herramientas existen, cuánto cuestan y para qué son. Eso es lo que hacen MCP y las agent skills publicadas. ## Dónde encaja MCP y dónde no MCP te da una forma estándar de exponer herramientas y recursos a un modelo, y es el transporte correcto. No es un modelo de autorización, y tratarlo como si lo fuera es el error más común en este terreno. El protocolo transporta tus decisiones; no las toma. Las preguntas de diseño que hay debajo son las de siempre. Para qué inquilino es esta llamada. Cuáles de sus registros puede ver este alcance. Quién aprueba una escritura. Qué se registra para poder reconstruir un incidente. Hemos escrito ambas mitades en detalle: [arquitectura de autorización MCP para empresas](/es/blog/enterprise-mcp-authorization-architecture/) para el diseño de referencia multiinquilino, y [los límites de seguridad de MCP](/es/blog/mcp-security-boundary-data-level-access-control/) para explicar por qué solo la aplicación a nivel de datos aguanta. Las agent skills se sitúan sobre las herramientas como capa de instrucciones: cuándo usar cuál, cuáles son las reglas de la casa, qué no hacer nunca. Herramientas sin skills se usan mal; skills sin herramientas son consejos. Publicamos las nuestras como archivos estáticos con sumas de verificación, para que cualquiera pueda leer qué se les dice a nuestros agentes. ## Un plan por etapas que no exige fe No necesitas creer que el tráfico de agentes será grande para justificar los dos primeros pasos, porque son baratos y también rinden para las personas. 1. **Primero herramientas de solo lectura.** Búsqueda, consulta, estado. Sin escrituras, sin aprobaciones que diseñar, y ejercita identidad y límites de tasa en condiciones reales. 2. **Publica el mapa.** Un endpoint MCP más skills que describan las herramientas con honestidad, incluido lo que van a rechazar. 3. **Una escritura, detrás de aprobación.** Elige el cambio de estado menos peligroso, añade claves de idempotencia y pon una confirmación humana delante. Registra todo. 4. **Amplía con evidencia.** Quita la aprobación solo en operaciones donde el registro muestre que el agente ha acertado de forma consistente, y mantenla en todo lo demás. Los pasos uno y dos son unos días de trabajo sobre una API bien factorizada y son útiles de inmediato, porque los mismos esquemas y mensajes de error facilitan tus propias integraciones. El paso tres es donde está el verdadero trabajo de diseño. ## La parte honesta Nadie puede decirte hoy cuántos ingresos llegan a través de agentes. Quien te dé una cifra está adivinando, y nosotros no vamos a adivinar por ti. Lo defendible es la forma de la apuesta. La superficie de solo lectura es barata, los estándares están convergiendo, y el trabajo no se pierde si el tráfico de agentes sigue siendo pequeño, porque herramientas tipadas, límites de autorización reales y errores legibles por máquinas son cosas que una API madura debería tener de todos modos. Lo que no haríamos es rediseñar un producto en torno a un canal que aún no se ha demostrado. Empieza por la parte que sirve en cualquier caso. ## Preguntas frecuentes ### ¿Cuál es la diferencia entre un producto legible por agentes y uno usable por agentes? Legible significa que un asistente puede descargar, interpretar, citar y atribuir tu contenido. Usable significa que puede autenticarse como un usuario concreto, llamar a una herramienta, cambiar estado y recibir un rechazo cuando corresponde. Lo primero es un problema de publicación, lo segundo de autorización e identidad. ### ¿Basta un servidor MCP para que un producto sea usable por agentes? No. MCP es el transporte para exponer herramientas y recursos; transporta tus decisiones de autorización en lugar de tomarlas. El alcance por inquilino, los permisos a nivel de datos, la aprobación de escrituras y el registro de auditoría tienen que existir detrás. ### ¿Por qué los agentes necesitan claves de idempotencia? Porque los agentes reintentan, incluso ante timeouts que malinterpretan y respuestas parciales que no entendieron. Sin una clave que convierta el segundo intento en una operación nula, un reintento se vuelve un pedido, un mensaje o un cargo duplicado. ### ¿Podemos exponer simplemente nuestra API REST actual? A menudo sí, con dos cambios. Los errores tienen que decir qué campo falló y qué se esperaba, para que un modelo pueda corregirse en lugar de entrar en bucle. Y los alcances tienen que expresar que un agente actúa en nombre de un usuario, en lugar de una única clave con todo habilitado. ### ¿Deberían los agentes poder escribir en producción? Con el tiempo, y de forma limitada. Empieza en solo lectura, pon después una escritura de bajo riesgo detrás de aprobación humana con idempotencia y registro completo, y quita la aprobación solo donde el registro muestre un historial consistente de comportamiento correcto. ### ¿Es demasiado pronto para invertir en esto? Para una reconstrucción completa, sí. Para herramientas de solo lectura y skills publicadas, no, porque las herramientas tipadas, los límites de autorización reales y los errores legibles por máquinas mejoran tus propias integraciones crezca o no el tráfico de agentes. ## Reflexiones finales Legible es un problema de publicación y está casi resuelto generando copias limpias y dejando entrar a los fetchers correctos. Usable es un problema de ingeniería, y lo limita la precisión con la que puedes decir no. Haz la superficie de solo lectura porque rinde de todos modos. Después diseña el camino de escritura alrededor de identidad, autorización a nivel de datos, idempotencia y auditoría, y amplíalo con evidencia en lugar de con optimismo. ## También te puede gustar.. [**Arquitectura de autorización MCP para empresas** Un diseño de referencia multiinquilino y neutral respecto a proveedores para exponer herramientas a agentes sin ampliar el radio de impacto.](/es/blog/enterprise-mcp-authorization-architecture/) [**AI enablement vs contratar IA en plantilla** Cuándo comprar la capacidad y cuándo contratarla, con el punto de equilibrio honesto.](/es/compare/ai-enablement-vs-in-house-ai-hire/) Ingeniería de agentes ## Continúa por este clúster Agentes de código, MCP, contexto, evaluación y controles para automatización fiable. [Empieza por el artículo fundamental**Ingeniería de grafos para agentes de IA: ¿Cuándo compensa un knowledge graph?**](/es/blog/graph-engineering-ai-agents/) - [Webs legibles por agentes: llms.txt, espejos en Markdown y qué se rompe](/es/blog/agent-readable-website-llms-txt-markdown-mirrors/) - [Las URLs traducidas rompen hreflang: usa un solo slug en inglés](/es/blog/english-slugs-vs-localized-urls-hreflang/) - [Graft Review 2026: ¿el mapa del repo debe ir en Git?](/es/blog/graft-review-agent-repo-map/) - [Cómo controlar los costes de agentes de código con compresión de salida](/es/blog/codag-cost-control/) - [Uso de tokens más inteligente con tu agente de programación IA](/es/blog/smarter-token-usage-with-your-ai-coding-agent/) Tu bandeja, sin ruido ## Sigue el trabajo que te importa Recibe un correo breve cuando publiquemos algo nuevo. Sigue todo el blog o solo los temas que te interesan. [**Volver**](/es/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/es/team/kevin-riedl/) [Kevin Riedl](/es/team/kevin-riedl/) https://linkedin.com/in/wsdt 8 min de lectura · 18 ago 2026 Última revisión 18 de agosto de 2026 [**Siguiente**](/es/blog/agent-readable-website-llms-txt-markdown-mirrors/) Nuevos artículos por correo × × Recibe nuevos artículos por correo Un correo breve cuando publicamos. Gratis y sin seguimiento. ## Structured Data ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ], "employee": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "founder": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "legalRepresentative": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "name": "Wavect GmbH", "subjectOf": { "@id": "https://wavect.io/verified-claims.json#dataset", "@type": "Dataset", "creator": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.", "inLanguage": "en", "isAccessibleForFree": true, "license": "https://creativecommons.org/licenses/by/4.0/", "name": "Wavect verified publication claims", "url": "https://wavect.io/verified-claims.json" }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/#website", "@type": "WebSite", "inLanguage": [ "en", "de", "es", "zh" ], "name": "Wavect", "potentialAction": { "@type": "SearchAction", "query-input": "required name=search_term_string", "target": { "@type": "EntryPoint", "urlTemplate": "https://wavect.io/search/?q={search_term_string}" } }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/es/blog/can-an-ai-agent-use-your-product/#webpage", "@type": "WebPage", "dateModified": "2026-08-18", "inLanguage": "es", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "lastReviewed": "2026-08-18", "url": "https://wavect.io/es/blog/can-an-ai-agent-use-your-product/" } ] } ``` ```json { "@context": "https://schema.org", "@type": "BlogPosting", "abstract": "Ser legible para un agente y ser usable por uno son proyectos distintos, y la mayoría de los equipos solo ha hecho el primero. Legible significa que un asistente puede descargar, interpretar, citar y atribuirte. Usable significa que puede autenticarse como un usuario concreto, llamar a una herramienta, cambiar estado y ser rechazado cuando corresponde. Lo segundo es sobre todo un problema de autorización, identidad y semántica de errores más que de modelo, y su ritmo lo marca la precisión con la que puedes decir no, porque un error de legibilidad cuesta una cita mientras que uno de autorización cuesta un incidente. Una superficie de herramientas usable necesita cinco cosas: identidad delegada que exprese qué agente actúa por qué usuario y en qué alcance, autorización aplicada en la capa de datos y no en el prompt, claves de idempotencia porque los agentes reintentan ante timeouts que malinterpretan, mensajes de error que nombren el campo que falló para que el modelo se corrija en lugar de entrar en bucle, y descubrimiento mediante MCP y agent skills publicadas. MCP es el transporte y no el modelo de autorización; tratarlo como tal es el error habitual. Una secuencia defendible es herramientas de solo lectura, después un mapa publicado, después una escritura de bajo riesgo detrás de aprobación humana, y después ampliar solo donde el registro de auditoría muestre un comportamiento consistentemente correcto. Hoy nadie puede cuantificar los ingresos que llegan por agentes, así que el argumento para los primeros pasos se apoya en que son baratos y útiles para las integraciones humanas de todos modos.", "articleBody": " Resumen del blog/IA y agentes/Ingeniería de agentes ¿Puede un agente de IA usar tu producto, o solo leer sobre él? Resumen Ser legible para un agente y ser usable por uno son proyectos distintos, y la mayoría de los equipos solo ha hecho el primero. Legible significa que un asistente puede descargar, interpretar, citar y atribuirte. Usable significa que puede autenticarse como un usuario concreto, llamar a una herramienta, cambiar estado y ser rechazado cuando corresponde. Lo segundo es sobre todo un problema de autorización, identidad y semántica de errores más que de modelo, y su ritmo lo marca la precisión con la que puedes decir no, porque un error de legibilidad cuesta una cita mientras que uno de autorización cuesta un incidente. Una superficie de herramientas usable necesita cinco cosas: identidad delegada que exprese qué agente actúa por qué usuario y en qué alcance, autorización aplicada en la capa de datos y no en el prompt, claves de idempotencia porque los agentes reintentan ante timeouts que malinterpretan, mensajes de error que nombren el campo que falló para que el modelo se corrija en lugar de entrar en bucle, y descubrimiento mediante MCP y agent skills publicadas. MCP es el transporte y no el modelo de autorización; tratarlo como tal es el error habitual. Una secuencia defendible es herramientas de solo lectura, después un mapa publicado, después una escritura de bajo riesgo detrás de aprobación humana, y después ampliar solo donde el registro de auditoría muestre un comportamiento consistentemente correcto. Hoy nadie puede cuantificar los ingresos que llegan por agentes, así que el argumento para los primeros pasos se apoya en que son baratos y útiles para las integraciones humanas de todos modos. Ser legible para un agente y ser usable por uno son proyectos distintos, y casi todos los equipos han hecho solo el primero. Legible significa que un asistente puede resumirte y citarte. Usable significa que puede completar una tarea en tu producto en nombre de una persona concreta, y que puede ser detenido cuando corresponde. Lo segundo no es, en su mayor parte, un problema de modelo. Es un problema de autorización, identidad y semántica de errores, y por eso aterriza en ingeniería y no en marketing. Dos preguntas distintas LegibleUsable Qué hace el agenteDescarga, interpreta, cita, atribuyeSe autentica, llama, cambia estado, informa de vuelta SuperficieHTML, espejo en Markdown, llms.txt, JSON-LDHerramientas con esquemas, identidad, permisos, auditoría FalloEstás ausente de la respuestaPasa algo que no debería haber pasado Coste de equivocarseAtención perdidaDatos, dinero o confianza perdidos Esa última fila es la razón de que la segunda columna lleve más tiempo. Un error de legibilidad te cuesta una cita. Un error de autorización te cuesta un incidente, así que el ritmo del trabajo lo marca la seguridad con la que puedes decir no. Si la primera columna aún no está hecha, empieza ahí. Nuestra guía de webs legibles por agentes lo cubre, y es una fracción del esfuerzo. Qué exige de verdad \"usable\" Una superficie de herramientas que un agente pueda operar necesita cinco cosas, y las interesantes no son la API. Identidad que no sea la del agente. El agente actúa por un usuario o un inquilino. Si tus tokens no pueden expresar \"este agente, en nombre de esta persona, para este alcance, hasta este momento\", en la práctica cada llamada es una llamada de administrador. Autorización en la capa de datos. Filtrar en el prompt no es control de acceso. El límite va donde se ejecuta la consulta, para que una instrucción persuasiva no pueda ensancharlo. Idempotencia. Los agentes reintentan. Reintentan ante timeouts que malinterpretan y respuestas parciales que no entendieron. Toda llamada que cambie estado necesita una clave que convierta el segundo intento en una operación nula. Semántica de errores sobre la que un modelo pueda actuar. Un 400 que dice \"petición inválida\" produce un bucle de reintentos. Uno que dice qué campo falló y qué forma esperaba produce una llamada corregida. Esto es documentación como superficie de control. Descubrimiento. Algo tiene que decirle al agente que las herramientas existen, cuánto cuestan y para qué son. Eso es lo que hacen MCP y las agent skills publicadas. Dónde encaja MCP y dónde no MCP te da una forma estándar de exponer herramientas y recursos a un modelo, y es el transporte correcto. No es un modelo de autorización, y tratarlo como si lo fuera es el error más común en este terreno. El protocolo transporta tus decisiones; no las toma. Las preguntas de diseño que hay debajo son las de siempre. Para qué inquilino es esta llamada. Cuáles de sus registros puede ver este alcance. Quién aprueba una escritura. Qué se registra para poder reconstruir un incidente. Hemos escrito ambas mitades en detalle: arquitectura de autorización MCP para empresas para el diseño de referencia multiinquilino, y los límites de seguridad de MCP para explicar por qué solo la aplicación a nivel de", "articleSection": "Engineering", "author": { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/" }, "dateModified": "2026-08-18", "datePublished": "2026-08-18", "description": "Ser legible para un agente y ser usable por uno son proyectos distintos, y la mayoría de los equipos solo ha hecho el primero. Legible significa que un asistente puede descargar, interpretar, citar y atribuirte. Usable significa que puede autenticarse como un usuario concreto, llamar a una herramienta, cambiar estado y ser rechazado cuando corresponde. Lo segundo es sobre todo un problema de autorización, identidad y semántica de errores más que de modelo, y su ritmo lo marca la precisión con la que puedes decir no, porque un error de legibilidad cuesta una cita mientras que uno de autorización cuesta un incidente. Una superficie de herramientas usable necesita cinco cosas: identidad delegada que exprese qué agente actúa por qué usuario y en qué alcance, autorización aplicada en la capa de datos y no en el prompt, claves de idempotencia porque los agentes reintentan ante timeouts que malinterpretan, mensajes de error que nombren el campo que falló para que el modelo se corrija en lugar de entrar en bucle, y descubrimiento mediante MCP y agent skills publicadas. MCP es el transporte y no el modelo de autorización; tratarlo como tal es el error habitual. Una secuencia defendible es herramientas de solo lectura, después un mapa publicado, después una escritura de bajo riesgo detrás de aprobación humana, y después ampliar solo donde el registro de auditoría muestre un comportamiento consistentemente correcto. Hoy nadie puede cuantificar los ingresos que llegan por agentes, así que el argumento para los primeros pasos se apoya en que son baratos y útiles para las integraciones humanas de todos modos.", "headline": "¿Puede un agente de IA usar tu producto, o solo leer sobre él?", "image": "https://wavect.io/img/blog/headers/header_can-an-ai-agent-use-your-product.svg", "inLanguage": "es", "keywords": "Visibilidad en IA, MCP", "mainEntityOfPage": { "@id": "https://wavect.io/es/blog/can-an-ai-agent-use-your-product/", "@type": "WebPage" }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/es/blog/can-an-ai-agent-use-your-product/", "wordCount": 1865 } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "item": "https://wavect.io/es/", "name": "Inicio", "position": 1 }, { "@type": "ListItem", "item": "https://wavect.io/es/blog/overview/", "name": "Resumen del blog", "position": 2 }, { "@type": "ListItem", "item": "https://wavect.io/es/blog/topics/ai-agents/", "name": "IA y agentes", "position": 3 }, { "@type": "ListItem", "item": "https://wavect.io/es/blog/clusters/agent-engineering/", "name": "Ingeniería de agentes", "position": 4 }, { "@type": "ListItem", "item": "https://wavect.io/es/blog/can-an-ai-agent-use-your-product/", "name": "¿Puede un agente de IA usar tu producto, o solo leer sobre él? | ", "position": 5 } ] } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Legible significa que un asistente puede descargar, interpretar, citar y atribuir tu contenido. Usable significa que puede autenticarse como un usuario concreto, llamar a una herramienta, cambiar estado y recibir un rechazo cuando corresponde. Lo primero es un problema de publicación, lo segundo de autorización e identidad." }, "name": "¿Cuál es la diferencia entre un producto legible por agentes y uno usable por agentes?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "No. MCP es el transporte para exponer herramientas y recursos; transporta tus decisiones de autorización en lugar de tomarlas. El alcance por inquilino, los permisos a nivel de datos, la aprobación de escrituras y el registro de auditoría tienen que existir detrás." }, "name": "¿Basta un servidor MCP para que un producto sea usable por agentes?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Porque los agentes reintentan, incluso ante timeouts que malinterpretan y respuestas parciales que no entendieron. Sin una clave que convierta el segundo intento en una operación nula, un reintento se vuelve un pedido, un mensaje o un cargo duplicado." }, "name": "¿Por qué los agentes necesitan claves de idempotencia?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "A menudo sí, con dos cambios. Los errores tienen que decir qué campo falló y qué se esperaba, para que un modelo pueda corregirse en lugar de entrar en bucle. Y los alcances tienen que expresar que un agente actúa en nombre de un usuario, en lugar de una única clave con todo habilitado." }, "name": "¿Podemos exponer simplemente nuestra API REST actual?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Con el tiempo, y de forma limitada. Empieza en solo lectura, pon después una escritura de bajo riesgo detrás de aprobación humana con idempotencia y registro completo, y quita la aprobación solo donde el registro muestre un historial consistente de comportamiento correcto." }, "name": "¿Deberían los agentes poder escribir en producción?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Para una reconstrucción completa, sí. Para herramientas de solo lectura y skills publicadas, no, porque las herramientas tipadas, los límites de autorización reales y los errores legibles por máquinas mejoran tus propias integraciones crezca o no el tráfico de agentes." }, "name": "¿Es demasiado pronto para invertir en esto?" } ] } ```