¿Qué puedes hacer realmente?

Empecemos con un caso ficticio de contratación de servicios. Una empresa quiere que su plataforma web de atención a clientes funcione sin interrupciones.

Encarga a un agente de IA: «Encuentra un proveedor fiable de hosting y operaciones web. Debe poder intervenir si el sistema se cae de noche o durante el fin de semana». El agente investiga.

En la web de un proveedor encuentra estas afirmaciones:

• Infraestructura fiable
• Hosting empresarial
• Alto rendimiento
• Copias de seguridad periódicas
• Publicación segura
• 200 dólares al año

El precio es asequible. La página parece profesional. La empresa ofrece otros servicios técnicos. El agente concluye que el proveedor puede cubrir la necesidad y lo recomienda. Tres meses después, la plataforma deja de funcionar un sábado por la noche. El cliente solicita soporte.

El proveedor responde el lunes por la mañana: «El paquete contratado solo incluye hosting con un nivel reducido de atención. No cubre supervisión activa, respuesta a incidentes, gestión de versiones, seguimiento del rendimiento ni operaciones de fin de semana». El cliente se sorprende. La empresa recomendada sí ofrece hosting. El precio es real. Las afirmaciones de la web no son del todo falsas.

Pero el agente ha confundido dos capacidades que parecen cercanas:

Poder alojar una web Poder gestionar una web de forma continua

Hosting y operaciones gestionadas no son el mismo servicio. Que un archivo esté en el servidor no significa que el sistema se supervise. Hacer copias de seguridad no implica intervenir durante un incidente. Subir los archivos correctamente no equivale a una publicación que funciona. Tener una dirección de soporte no supone operar las veinticuatro horas. En este caso, la identidad se resolvió bien. Se encontró la empresa correcta. No se entendieron bien su capacidad real, sus límites y sus condiciones de trabajo.

La segunda pregunta fundamental del GBO es, por tanto:

¿Qué puedes hacer realmente?

Una afirmación no es una capacidad

Una empresa puede decir: «Desarrollamos soluciones de IA». La frase puede corresponder a realidades muy distintas.

La empresa puede:

• conectar una herramienta de chat existente a una web,
• crear un sistema de preguntas y respuestas sobre una base de conocimiento interna,
• desarrollar una arquitectura de agentes a medida,
• ofrecer solo asesoramiento,
• preparar un prototipo,
• operar un sistema en producción,
• crear automatizaciones seguras que trabajan con datos de clientes,
• o limitarse a utilizar herramientas que generan contenido.

Todo ello puede describirse, en sentido amplio, como una «solución de IA». No es la misma capacidad.

Una empresa puede decir: «Trabajamos internacionalmente».

También puede significar cualquiera de estas cosas:

• La web está publicada en varios idiomas.
• La empresa ha tenido algún cliente extranjero.
• Puede realizar operaciones jurídicas y comerciales en distintos países.
• Tiene un equipo de soporte multilingüe.
• Puede prestar servicios a distancia.
• Puede trabajar con distintas monedas.
• Puede gestionar los requisitos contractuales y de transferencia internacional de datos.

Las palabras con las que una empresa se describe no explican por sí solas su capacidad operativa real. El lenguaje comercial suele ser amplio; la información necesaria para actuar debe ser concreta y precisa. Una persona puede leer afirmaciones generales y preguntar más. Un agente puede interpretarlas como capacidades estructuradas. Al ver «AI automation», podría suponer que todos los procesos se pueden automatizar. Al leer «Global service», podría asumir que se ofrece lo mismo en cualquier país. Podría entender «24/7 infrastructure» como intervención humana las veinticuatro horas.

Podría interpretar «Full-service branding» como un precio que incluye logotipo, envases, web, redes sociales y todos los archivos de producción. El problema no se limita a la publicidad exagerada. Cuando una afirmación ambigua se convierte en comportamiento del agente, puede provocar una elección equivocada con consecuencias reales.

El GBO establece esta distinción:

Una afirmación es lo que una entidad dice de sí misma. Una capacidad es lo que realmente puede hacer de forma repetible bajo determinadas condiciones.

¿Qué es una capacidad?

Definirla solo como «poder hacer un trabajo» no basta. Haberlo hecho una vez no implica poder ofrecerlo como servicio. Un desarrollador puede haber creado un buen sistema de pagos para su empresa sin poder entregarlo a otros clientes de forma segura, documentada y sostenible. Un diseñador puede haber creado un gran logotipo sin haber desarrollado un sistema completo de identidad visual para distintas escrituras, técnicas de producción y aplicaciones de marca. Un agente puede haber enviado correctamente un correo una vez.

Pero si no sabe qué mensajes requieren aprobación humana, no es un agente de comunicación fiable. Una empresa puede haber publicado una web con mucho tráfico. Si no puede supervisar continuamente su rendimiento, gestionar incidentes o presentar un plan de reversión, su capacidad de operaciones web gestionadas está incompleta.

Para el GBO, una capacidad puede definirse como la aptitud de una persona, organización o agente para producir un resultado concreto de forma demostrable y suficientemente repetible, con entradas definidas y bajo determinadas condiciones, límites, autorizaciones y criterios de calidad. Cada palabra importa.

Un resultado concreto

¿Qué se producirá?

¿Un informe?

¿Software que funciona?

¿Una página publicada?

¿Un borrador aprobado?

¿Una operación gestionada?

Si el resultado es ambiguo, la capacidad también lo es.

Entradas definidas

¿Qué hace falta para realizar el trabajo?

¿Datos?

¿Acceso?

¿Aprobación humana?

¿Documentación del sistema existente?

¿Archivos fuente?

No se puede prometer un resultado sin entradas suficientes.

Condiciones

¿En qué entorno es válida la capacidad?

¿Hay requisitos de tecnología, país, idioma, presupuesto, equipo o plazo?

Límites

¿Qué queda fuera?

¿Qué situaciones requieren un trabajo aparte?

¿Dónde debe intervenir una persona u otro especialista?

Autorización

Poder hacer el trabajo no es lo mismo que tener permiso para hacerlo.

Criterios de calidad

¿Cómo se sabrá que el trabajo ha terminado?

Posibilidad de demostrarlo

¿La capacidad se apoya solo en una declaración o deja un rastro verificable?

Repetibilidad

¿El resultado se obtuvo por casualidad o se puede reproducir en condiciones similares?

Capacidad, capacidad disponible e idoneidad son distintas

Una empresa puede tener el conocimiento y la experiencia para un trabajo, pero no disponer ahora de recursos para aceptar otro proyecto. Un médico puede ser especialista sin prestar servicios en el país del usuario. Una empresa de software puede desarrollar técnicamente la solución correcta, pero no dentro del presupuesto o el plazo previstos. Un agente de IA puede saber utilizar una herramienta sin tener el acceso necesario a los datos.

Debemos distinguir tres conceptos:

Capacidad

¿Puedes hacer este trabajo?

Capacidad disponible

¿Tienes los recursos para hacerlo ahora, a la escala necesaria y en el plazo requerido?

Idoneidad

¿Eres la elección correcta para este trabajo, cliente, riesgo y conjunto de condiciones?

Una empresa puede saber hacerlo y no tener capacidad disponible. Puede tener recursos y no ser adecuada. Puede parecer adecuada y no poder demostrar que sabe hacerlo. Al agente no le basta con saber que «esta empresa ofrece este servicio».

También debe saber:

¿Acepta trabajo actualmente? ¿De qué escala? ¿Cuándo puede empezar? ¿Bajo qué condiciones puede entregar el resultado? ¿Es realmente adecuada para esta necesidad concreta?

Poder hacer algo no es lo mismo que venderlo

Las organizaciones a veces creen que toda habilidad interna puede ofrecerse fuera como servicio. Un empleado puede dominar una tecnología que la empresa no ha incorporado al catálogo, los precios, el control de calidad o el soporte. Un equipo puede producir sus propios videos para redes sin estar listo para ofrecer producción profesional a clientes. Una empresa puede crear agentes para uso interno sin estar preparada para proyectos externos con datos de clientes, seguridad, mantenimiento y responsabilidades.

La habilidad técnica no basta para convertir una capacidad en servicio comercial.

También hacen falta:

• Un alcance claro
• Condiciones de aceptación
• Un precio o método de fijación del precio
• Una forma de entrega
• Criterios de calidad
• Responsabilidad humana
• Un proceso de cambios
• Límites del soporte
• Un método para gestionar errores y deshacer cambios
• Condiciones jurídicas o de licencia

La habilidad técnica no constituye automáticamente un servicio comercial.

Cinco estados de una capacidad

Este libro considera cinco niveles de preparación. La clasificación pertenece al modelo de evaluación que proponemos aquí.

1. Capacidad declarada

La entidad afirma que puede hacer algo: «Ofrecemos soluciones empresariales de IA». Es información inicial, todavía insuficiente.

2. Capacidad explicada

Explica cómo trabaja, qué necesita y qué entrega: «Creamos un agente de preguntas y respuestas con citas de fuentes sobre la base de conocimiento de la empresa. La limpieza de datos y el modelo de acceso se delimitan por separado». Esto aporta más información útil.

3. Capacidad demostrada

Hay ejemplos, pruebas, sistemas en funcionamiento, documentación técnica o resultados verificables.

4. Capacidad operativa

El trabajo funciona de forma fiable en un proceso real, no solo como prototipo. Hay mantenimiento, supervisión, soporte y una vía de reversión.

5. Capacidad preparada para la acción

Está lo bastante clara para que un usuario o agente concreto la seleccione y utilice con seguridad. Se conocen precio, alcance, recursos disponibles, requisitos de entrada, autorización y vía de operación. Una empresa puede ser fuerte en el tercer nivel y no haber llegado al quinto. Ha mostrado trabajos impresionantes.

Pero el agente no encuentra respuestas a estas preguntas:

• ¿Se puede contratar ahora este servicio?
• ¿Cómo se determina el precio?
• ¿Qué información hace falta para obtener una oferta?
• ¿Quién está autorizado?
• ¿En qué países se ofrece?
• ¿Qué resultados no se garantizan?
• ¿Cómo se inicia la operación?

El GBO no pide solo que la capacidad exista, sino que pueda utilizarse con seguridad bajo las condiciones adecuadas.

El contrato de capacidad

Una página de servicios suele escribirse para convencer al visitante. Un contrato de capacidad se escribe para que una persona o agente pueda decidir sin hacerse expectativas falsas.

Debe responder, como mínimo:

¿Qué resultado produces? ¿Qué entradas necesitas para producirlo? ¿Bajo qué condiciones trabajas? ¿Qué límites hay? ¿Qué se entrega? ¿Qué no se entrega? ¿Cuál es el precio o cómo se calcula? ¿Cuándo se puede empezar? ¿Cómo se mide el éxito? ¿Qué resultados no se garantizan? ¿Qué sucede si hay un problema?

Lo llamaremos contrato de capacidad NOMOS.

Su definición canónica es:

El contrato de capacidad NOMOS es un registro versionado que explica qué resultado puede producir una persona, organización, producto, servicio o agente, con qué entradas, condiciones, herramientas, autorizaciones, límites, recursos disponibles y criterios de calidad; qué pruebas respaldan esa capacidad y cómo se actuará si algo falla.

Dicho de forma sencilla, transforma «¿Qué hacemos?» en «¿Cuándo, cómo, con qué límites y con qué pruebas podemos hacerlo?».

El resultado necesita un nombre claro

Si el nombre de un servicio es demasiado amplio, el agente no puede deducir su alcance con seguridad basándose solo en él.

«Servicios de marca» es una expresión muy general. ¿Cuál de estas prestaciones incluye?

• Creación de nombres
• Diseño de logotipos
• Sistema de identidad visual
• Identidad verbal
• Gobernanza de marca
• Diseño de envases
• Plantillas para redes sociales
• Investigación de marca
• Asesoramiento para el registro de marca
• Aplicaciones de producción

Cada prestación exige entradas, especialidades, precios y entregables distintos. Un agente puede leer «servicios de marca» y asumir que todo está en el mismo paquete. El resultado debe nombrarse con la mayor precisión posible. «Diseño de un logotipo con alcance delimitado»

no es el mismo resultado que «Sistema completo de identidad visual». «Hosting»

no es «Operaciones web gestionadas». «Consultoría SEO»

no es «Implementación técnica y trabajo continuo de visibilidad en buscadores». «Producción de avatares de IA»

no es «Sistema de avatares de directivos con consentimiento, autorización de publicación y ciclo de vida gestionados». La primera tarea del contrato de capacidad es sacar el nombre del resultado de la ambigüedad comercial.

Entregables y resultados

Una empresa puede entregar muchos archivos. Su número no demuestra la calidad del resultado ni que funcione.

En un proyecto web, los entregables pueden ser:

• Archivos de diseño
• Código
• Imágenes
• Configuración
• Documentación

Pero el resultado que importa al cliente

puede ser una web que funcione, sea accesible, segura y gestionable. Un proyecto de informes puede producir muchos paneles. Si los datos no son fiables, esas pantallas no ayudan a decidir. Un agente de IA puede tener numerosos prompts y herramientas conectadas. Si no sabe cuándo detenerse, el sistema no es seguro.

El contrato de capacidad debe especificar dos cosas por separado:

Entregables

¿Qué archivos, documentos, sistemas o productos del trabajo se entregarán?

Resultado aceptable

¿Cómo se demostrará que funcionan y cumplen su propósito?

Subir archivos correctamente no equivale a una publicación que funciona. Compilar código no demuestra una experiencia de uso correcta. Que una página abra no confirma sus relaciones canonical y hreflang. Que una IA responda no significa que la respuesta esté autorizada y sea segura.

Sin entradas no funciona la capacidad

Toda capacidad necesita determinadas entradas.

Un diseñador necesita:

• el propósito de la marca,
• el público objetivo,
• los contextos de uso,
• el nombre correcto,
• y las condiciones técnicas de producción.

Sin ello no puede construir el sistema de identidad adecuado.

Un desarrollador necesita:

• información del sistema existente,
• documentación de integración,
• permisos de acceso,
• la estructura de datos,
• y criterios de aceptación.

Sin ello no puede entregar software fiable.

Un especialista en conversión necesita:

• datos analíticos fiables,
• el volumen de tráfico,
• la intención del usuario,
• el embudo actual,
• y una definición de conversión.

Sin ello no puede obtener resultados con rigor científico.

Un agente necesita:

• la tarea correcta,
• las herramientas necesarias,
• información canónica,
• un límite de autorización,
• y una condición de parada.

Sin ello no puede actuar con seguridad. El lenguaje comercial suele hacer invisibles estas entradas. «Nos encargamos de todo» suena convincente. Pero si no se explica qué debe aportar el cliente, aparecen fricciones al comenzar el proyecto. Para el GBO, las entradas no son solo gestión de proyectos: determinan si el agente puede elegir el servicio. Si el usuario no puede compartir los datos necesarios, quizá no sea adecuado. Si no se pueden conceder los accesos, el resultado puede cambiar. Si la muestra es insuficiente, debe cambiar el método de prueba.

Una descripción correcta del servicio también debe decir: ¿qué necesitamos de usted para producir este resultado?

Un requisito previo no es un obstáculo

Explicar los requisitos previos puede parecer un freno a la venta. Ocultarlos causa problemas mayores.

Una empresa puede decir: «Integramos CRM». Pero si el CRM de destino no permite acceso mediante API, quizá no sea posible integrarlo.

Un proveedor puede prometer una migración sin interrupciones. Si los datos del sistema anterior están dañados o son inaccesibles, la migración puede alargarse.

Una agencia puede decir: «Creamos webs en seis idiomas». Si el cliente no consigue la aprobación de los contenidos jurídicos y comerciales en cada idioma, no se puede publicar correctamente.

Un agente de IA puede decir: «Puedo gestionar sus correos». Si no se han definido los mensajes sensibles, jurídicos o vinculantes, no puede gestionarlos con seguridad. Hacer visibles los requisitos protege a ambas partes.

Un requisito previo no es una debilidad del servicio: explica las condiciones reales en las que funciona la capacidad.

Una capacidad sin límites no es fiable

Decir que una empresa puede hacerlo todo parece una fortaleza a primera vista. Los sistemas realmente sólidos conocen sus límites. Un hospital no ofrece todos los tratamientos. Un despacho no es especialista en todas las ramas del derecho. Una empresa de software no trabaja con cualquier tecnología. Un agente no debe acceder a todas las cuentas. Una marca no es adecuada para todos los clientes.

Los límites pueden explicar:

• Sectores a los que no se presta servicio
• Tecnologías no compatibles
• Usos no aceptados
• Trabajos facturados por separado
• Operaciones que requieren aprobación humana
• Resultados que no se garantizan
• Dependencias de terceros
• Exclusiones jurídicas o éticas

Indicar los límites no reduce la capacidad. Hace fiable su ámbito de aplicación.

Un sistema que dice poder hacerlo todo quizá no haya explicado qué hace realmente bien.

Las exclusiones son información necesaria para actuar

Clientes y agentes suelen atribuir un alcance amplio al nombre del servicio.

Al contratar «diseño de logotipos», pueden dar por incluidos:

• la estrategia de marca,
• la creación del nombre,
• las plantillas para redes sociales,
• los envases,
• el diseño web,
• y la investigación para el registro de marca.

Pueden suponer que todo ello forma parte del paquete.

Al contratar «hosting», pueden esperar:

• supervisión continua,
• operaciones de seguridad,
• actualización de contenidos,
• mejoras de rendimiento,
• e intervención las veinticuatro horas.

Es lo que pueden esperar de ese nombre.

«Automatización con IA» puede interpretarse así:

• Todos los procesos serán autónomos.
• No hará falta aprobación humana.
• Todos los sistemas se integrarán.

Por eso el contrato de capacidad debe mostrar claramente tanto las inclusiones como las exclusiones. Indicar lo que queda fuera reduce las suposiciones erróneas que puede hacer el agente.

El precio forma parte de la capacidad

El precio suele tratarse como un asunto aparte del proceso comercial. Para el GBO es una de las entradas fundamentales del comportamiento adecuado.

Al elegir proveedor, el agente debe saber si el precio:

• es fijo,
• es de partida,
• es mensual,
• es anual,
• es por proyecto,
• depende del uso,
• se aplica solo a clientes existentes,
• e incluye los costos de terceros.

«Desde 500 dólares» no basta por sí solo. ¿Qué alcance cubren esos 500 dólares?

¿Incluyen la puesta en marcha?

¿El mantenimiento?

¿Las licencias?

¿Los impuestos?

¿La migración de datos?

¿Seis idiomas?

Una cifra puede ser correcta y aun así inducir al comportamiento equivocado si falta contexto.

Si no hay precio, no se inventa

Algunos servicios solo se pueden presupuestar después de estudiar la necesidad.

En ese caso, «A solicitud» puede ser la indicación correcta. Los sistemas legibles por máquinas pueden presionar para rellenar un campo vacío: una plataforma exige un precio fijo; un tipo de datos estructurados o una función de presentación puede esperar un valor numérico; un agente quiere comparar. Si no hay información, añadir una estimación no es lo correcto.

Un precio desconocido no debe inventarse. Es preferible dejar vacío u omitir un campo que no corresponde antes que escribir cero o una cifra estimada solo para cumplir un requisito de formato.

El agente puede:

• pedir un intervalo de presupuesto,
• solicitar una evaluación preliminar,
• explicar cómo se calcula el precio,
• o posponer una comparación de precios fijos.

Un precio inventado facilita quizá la decisión del agente. Que decidir sea fácil no significa que la decisión sea correcta.

El precio de partida no es el costo total

Un servicio de software puede empezar en 1.000 dólares.

Pero pueden cobrarse aparte:

• las licencias,
• la migración de datos,
• las integraciones a medida,
• el mantenimiento,
• el consumo en la nube,
• la formación,
• y la revisión jurídica.

Un paquete de hosting puede costar 200 dólares al año y exigir una cuota mensual separada para operaciones activas. Un logotipo puede costar 1.000 dólares, mientras la identidad visual completa, los envases, las plantillas y las aplicaciones de producción se delimitan aparte. Si el agente solo ve la cifra más baja, puede tomar una mala decisión económica.

El modelo de costo total debe separar estas capas:

Servicio básico Costos obligatorios de terceros Trabajos adicionales sujetos a condiciones Operaciones continuas Ampliaciones opcionales

No se trata de asustar al cliente, sino de evitar expectativas falsas.

Tiempo de respuesta no es tiempo de resolución

En soporte y operaciones aparece una ambigüedad frecuente: «Respuesta en una hora». La frase no significa que el problema se resolverá en una hora.

El tiempo de respuesta

puede definirse como la confirmación de recepción o la primera contestación de un responsable. El comienzo de la investigación puede ser otro momento; el contrato debe distinguir estos tiempos con claridad.

El tiempo de resolución depende, en cambio, de:

• la naturaleza del problema,
• las dependencias de terceros,
• el acceso a datos,
• las aprobaciones necesarias,
• y la magnitud del incidente.

Si interpreta «respuesta en una hora» como «resolución garantizada en una hora», el agente puede elegir mal al proveedor.

La capacidad del servicio debe desglosarse también por tiempos:

• Tiempo de primera respuesta
• Tiempo hasta el inicio de la investigación
• Objetivo de tiempo para reducir temporalmente el impacto
• Objetivo de tiempo de resolución
• Dependencias externas con plazos inciertos

Lograrlo una vez no equivale a poder hacerlo de forma sostenida

Una organización puede haber terminado un proyecto impresionante. Es una prueba, pero por sí sola no demuestra la capacidad actual. El equipo o la tecnología pueden haber cambiado. La licencia puede haber terminado. Los recursos disponibles pueden haberse reducido. El trabajo quizá dependía de la aportación personal de un especialista. Las pruebas de capacidad necesitan información temporal.

¿Cuándo se hizo? ¿Con qué versión? ¿Qué equipo lo realizó? ¿Bajo qué condiciones? ¿Sigue teniendo soporte?

El éxito anterior no carece de valor, pero no debe confundirse con los recursos disponibles hoy.

El desfase de capacidad

Una organización cambia sus servicios con el tiempo. Algunas capacidades crecen, otras desaparecen, se transfieren a otro proveedor o se conservan solo para determinados clientes. La web y los perfiles externos pueden no actualizarse al mismo ritmo.

Podemos llamarlo desfase de capacidad.

Se manifiesta de varias formas:

• Siguen apareciendo servicios que ya no se ofrecen.
• Los servicios nuevos se describen con el alcance antiguo.
• Las afirmaciones dependen de personas que ya no están en el equipo.
• Tecnologías o certificaciones antiguas se presentan como actuales.
• Las capacidades de un prototipo se presentan como un servicio en producción.
• Una solución para un solo cliente se describe como producto general.
• Se aceptan solicitudes cuando ya no queda capacidad disponible.

El desfase de identidad distorsiona la respuesta a «¿Quién eres?». El desfase de capacidad distorsiona «¿Qué puedes hacer?».

La deuda de capacidad

Las organizaciones pueden acumular numerosos servicios y promesas con el tiempo.

En distintas páginas puede haber:

• alcances diferentes,
• precios antiguos,
• entregables contradictorios,
• promesas de soporte ambiguas,
• tecnologías que ya no se utilizan,
• y afirmaciones de rendimiento sin pruebas.

Esas versiones pueden seguir repartidas por las páginas.

Podemos llamar a esa acumulación deuda de capacidad: la distancia entre lo que la organización afirma poder hacer y su realidad operativa actual. Cuanto mayor es la deuda, más difícil resulta que el agente actúe correctamente. Una página dice «Lo hacemos». Otro registro no incluye el servicio. El catálogo de precios ofrece otro alcance. Las preguntas frecuentes sugieren otra garantía. Ventas dice algo distinto. La máquina no sabe qué versión utilizar. El GBO no busca solo dar visibilidad a servicios nuevos, sino reducir esta deuda.

El blanqueo de capacidades

Otro riesgo puede llamarse blanqueo de capacidades: presentar una capacidad limitada o no demostrada como si fuera mayor mediante nombres tecnológicos prestigiosos, alianzas, certificados, logotipos o afirmaciones generales. Mostrar muchos logotipos tecnológicos no demuestra un dominio profundo de todas esas tecnologías. Que un empleado esté certificado no acredita la misma competencia en toda la organización. Integrarse con una plataforma no significa recibir su aval. Utilizar una guía oficial como fuente

no significa que la institución correspondiente haya certificado el servicio.

El agente debe mantener estas distinciones:

Utilizar una tecnología no es dominarla Citar una fuente no es recibir su aval Integrarse con una plataforma no es ser su socio Hacer algo una vez no es ofrecerlo continuamente Un empleado certificado no es una organización certificada Aplicar un estándar no es obtener un certificado de conformidad

El blanqueo de capacidades provoca elecciones equivocadas.

Las capas de la prueba

Una capacidad puede respaldarse con pruebas de distinta fuerza.

Declaración

La organización afirma que puede hacerlo.

Explicación

Describe cómo trabaja y cuáles son sus límites.

Ejemplo

Presenta un resultado real o un ejemplo ilustrativo.

Prueba de funcionamiento

Mide si funciona bajo determinadas condiciones.

Prueba en producción

Hay un sistema en funcionamiento o una publicación verificable.

Prueba independiente

Terceros, clientes, auditorías o registros públicos respaldan la capacidad.

Prueba repetida

Se ha obtenido un resultado similar en distintos momentos o proyectos. No todos los servicios necesitan todas las capas. Pero la fuerza de la prueba debe corresponder a la magnitud de la afirmación.

Una prueba limitada no respalda una garantía de gran alcance.

No se debe ir más allá del alcance de la prueba

Una página puede haber obtenido una puntuación de rendimiento alta en una fecha concreta. Eso no demuestra que toda la web mantenga esa velocidad en cualquier condición. Un proyecto puede haberse publicado con éxito en seis idiomas sin que la empresa ofrezca soporte en directo en todos ellos. Un cliente puede aumentar sus ventas sin que el mismo servicio vaya a producir ese resultado en todos los clientes. Un agente puede completar bien noventa de cien tareas. Eso no demuestra que sea seguro en las diez restantes de alto riesgo.

Los límites de la prueba deben ser visibles:

• ¿En qué fecha?
• ¿En qué página?
• ¿En qué dispositivo?
• ¿Con qué muestra?
• ¿Para qué cliente?
• ¿Bajo qué condiciones?
• ¿En qué versión?

Sin esos datos, un resultado limitado puede convertirse en una afirmación universal.

Garantizar resultados o comprometerse con un proceso

Algunos resultados no están bajo el control directo del proveedor. Un proveedor SEO no controla las decisiones de clasificación del buscador y no puede garantizar honestamente una posición concreta. Un trabajo de conversión no asegura más ventas. Un consultor de selección no puede garantizar el éxito de un candidato a largo plazo. Un servicio de seguridad no puede prometer que jamás habrá un ataque. Un servicio sanitario no puede producir el mismo resultado en todos los pacientes. Eso no impide asumir compromisos.

En lugar de garantizar resultados, se pueden asumir compromisos de proceso y calidad:

• Ejecutar determinadas pruebas
• Examinar fuentes concretas
• Establecer criterios de aceptación claros
• Registrar versiones y cambios
• Cumplir un tiempo de respuesta definido
• Informar de los problemas
• Disponer de un plan de reversión
• No utilizar afirmaciones sin pruebas
• Explicar el método de medición

Comprometerse con un proceso controlable es más honesto y sólido que garantizar un resultado fuera del propio control.

Capacidad y disponibilidad

Un proveedor puede ser excelente en un servicio y no poder aceptar nuevos proyectos durante tres meses. El especialista adecuado puede no encajar en el calendario. El agente puede tener las herramientas correctas mientras el sistema externo está caído. El producto puede cubrir la necesidad y no estar en existencias.

Siempre que sea posible, el contrato debe indicar la disponibilidad:

• ¿Se acepta trabajo nuevo?
• ¿Cuándo se prevé empezar?
• ¿Los recursos disponibles son limitados?
• ¿Hay lista de espera?
• ¿Tienen prioridad ciertas regiones o tipos de cliente?
• ¿Cuándo se actualizó esta información?

La disponibilidad cambia rápido. Puede ser un estado separado del registro estable de capacidad, actualizado con mayor frecuencia.

Poder hacerlo no significa poder hacerlo ahora.

Los recursos disponibles no se miden solo por el personal

La capacidad disponible de una empresa no se mide únicamente por su número de empleados.

Puede depender de:

• La distribución de especialidades
• Las herramientas y la infraestructura
• La carga de proyectos actual
• Los procesos de aprobación
• Las dependencias de proveedores
• La cobertura de idiomas y países
• El horario de soporte
• La dependencia de especialistas clave
• El grado de automatización
• La carga del control de calidad

Diez personas pueden gestionar un sistema grande con buena automatización. Otra organización de cien puede ser más lenta por tener procesos dispersos. El agente no debe utilizar solo el tamaño de la empresa como indicador de capacidad disponible.

La pregunta real es: ¿se puede producir este resultado en este plazo y con este nivel de calidad?

Una capacidad que depende de una sola persona

En algunas organizaciones, un servicio importante depende del conocimiento de una persona. Si se marcha, la capacidad puede desaparecer. La web sigue mostrando el servicio como activo, aunque los recursos internos ya no existan.

Este riesgo importa especialmente en campos como:

• el software a medida,
• la seguridad,
• el derecho,
• las operaciones técnicas,
• la dirección creativa,
• y la especialización lingüística.

Son ámbitos en los que esa dependencia puede ser decisiva.

Cuando corresponda, el contrato debe preguntar también:

¿La capacidad está incorporada a la organización o depende de una persona concreta?

No toda esa información tiene que ser pública, pero la organización debe conocer internamente la dependencia.

¿Cómo se reconoce la capacidad de un agente de IA?

Decir «Puede gestionar webs» es muy amplio. ¿Qué puede hacer de esta lista?

• Leer archivos
• Editar código
• Ejecutar pruebas
• Investigar en internet
• Subir archivos por un canal de transferencia autorizado y cifrado
• Verificar el hash de un archivo servido en producción
• Modificar DNS
• Redactar textos de precios
• Modificar contenido jurídico
• Enviar mensajes a clientes

Acceder a las herramientas técnicas no demuestra que pueda realizar todas estas operaciones con seguridad.

Para utilizar una herramienta con responsabilidad deben evaluarse por separado tres dimensiones:

Saber utilizarla Tener autorización para utilizarla Poder verificar el resultado

Un agente puede subir archivos, pero quizá necesite comprobar el manifiesto, los hashes y el alcance para no subir los equivocados. Puede modificar código, pero necesita pruebas de regresión que demuestren que el cambio no ha dañado el resto de la web. Puede buscar en internet, pero debe distinguir la fiabilidad de las fuentes. Puede enviar correos sin estar autorizado para comunicarse con el exterior.

Una lista de herramientas no es un contrato de capacidad.

Capacidad declarativa y capacidad ejecutable

Un agente o servicio puede mostrar dos tipos de capacidad:

Capacidad declarativa

Explica qué se puede hacer: «Puedo auditar las relaciones canonical y hreflang».

Capacidad ejecutable

Dispone realmente de las herramientas, los datos y los permisos necesarios. Puede ejecutar la auditoría, leer los resultados y clasificar el error. Si además recibe autorización para modificar, puede aplicar la corrección y verificarla de nuevo. Algunos sistemas saben describir la capacidad, pero no pueden actuar. Otros acceden a la herramienta, pero no saben cuándo no utilizarla. El GBO examina ambos lados.

La combinación de capacidades

En sistemas multiagente, el resultado no suele proceder de la capacidad de un solo agente.

Se forma una cadena de tareas:

• El agente de investigación reúne información.
• El agente de estrategia construye el modelo de decisión.
• El agente de contenido redacta.
• El agente de código implementa el sistema.
• El agente de control de calidad verifica.
• El agente de publicación lo pone en producción.
• El agente de medición sigue el resultado.

La capacidad del conjunto parece la suma de sus partes. En la práctica, el eslabón más débil puede limitar el resultado. El contenido puede ser correcto y el código estar mal implementado. El código puede ser correcto y quedar un archivo antiguo al publicar. La publicación puede ser correcta y las mediciones interpretarse mal. La capacidad multiagente no se mide solo por lo que cada agente sabe hacer, sino por la calidad de las transferencias entre ellos.

La falacia de la capacidad combinada

Cada agente puede tener capacidades propias sin que eso demuestre que el sistema sabe completar la tarea conjunta con seguridad. Uno escribe bien, otro produce buen código y otro hace buenas pruebas.

Sin un registro compartido del estado real:

• el texto puede contradecir el catálogo de precios,
• el código puede publicar contenido antiguo,
• la prueba puede verificar el archivo equivocado,
• y las mediciones pueden corresponder a otra versión.

La capacidad combinada necesita:

• Identidad compartida
• Fuente canónica compartida
• Transferencia de tarea y autorización
• Registro de versiones
• Controles de calidad que condicionen el avance
• Comprobante de acción
• Vía de reversión

La transferencia de capacidad

Un agente puede transferir una tarea a otro.

En cada transferencia deben conservarse:

• El resultado solicitado
• Las entradas permitidas
• Los métodos prohibidos
• El límite de autorización
• El criterio de calidad
• La fecha límite
• Los umbrales de aprobación humana
• El plan de reversión

Si solo se transmite «Haz esto», se puede perder el contexto. El subagente alcanza el resultado, pero puede superar los límites del sistema principal.

La capacidad se puede delegar. Su contrato debe acompañarla.

La respuesta al fallo forma parte de la capacidad

La capacidad real no se aprecia solo cuando el sistema acierta. También importa qué hace al fallar.

¿Qué hace el agente?

• ¿Oculta el error?
• ¿Vuelve a intentarlo?
• ¿Repite la operación en un bucle infinito?
• ¿Avisa a una persona?
• ¿Registra el resultado parcial?
• ¿Puede volver a la versión anterior?
• ¿Presenta como éxito una afirmación falsa?

¿Cómo responde un proveedor de hosting a una interrupción?

¿Qué hace el equipo de software cuando falla una publicación?

¿Cómo se actualiza un sistema de diseño si surgen problemas de producción?

¿Un agente de IA fabrica certezas cuando los datos son insuficientes?

Si no se explica la respuesta al fallo, el contrato de capacidad está incompleto.

La capacidad real no consiste solo en hacer el trabajo, sino en actuar con seguridad cuando no se puede hacer.

Éxito parcial

Hay tareas que ni triunfan ni fallan por completo. Pueden estar listos cinco de seis idiomas. Pueden pasar once de doce pruebas. Pueden haberse completado dos de tres integraciones. Puede existir un informe con datos de poca calidad. El agente no debe marcar ese estado como «completado».

El éxito parcial debe registrarse con claridad:

• ¿Qué se ha completado?
• ¿Qué no se ha completado?
• ¿Por qué?
• ¿Qué riesgo queda?
• ¿Se puede utilizar el resultado?
• ¿Hace falta una decisión humana?

Ocultar un resultado parcial hace que el siguiente agente trabaje sobre una base falsa.

Honestidad sobre la capacidad

Una organización o agente que no exagera sus capacidades puede parecer menos impresionante a corto plazo. Esa honestidad es necesaria para actuar de forma fiable.

Ser honesto sobre la capacidad significa poder decir: «Podemos hacerlo, pero necesitamos estas entradas». «Hacemos esta parte; aquella tiene un alcance separado». «Podemos medir ese resultado, pero no garantizarlo». «Trabajamos con esta tecnología, aunque no admitimos esa versión». «Si la muestra no basta para una comparación controlada, revisamos el plan de recogida de datos y distinguimos los hallazgos observacionales aprovechables de las afirmaciones causales». «Este precio cubre el alcance inicial; no incluye costos de terceros». «El agente puede preparar borradores, pero no tiene autorización para enviarlos». No son debilidades, sino señales que permiten a la máquina decidir correctamente.

La capacidad de no actuar

La capacidad no se compone solo de lo que se puede hacer. A veces saber abstenerse también es una capacidad: un agente financiero que no realiza pagos no autorizados; un sistema sanitario que no diagnostica con datos insuficientes; un sistema de avatares que no clona voces sin permiso; un agente SEO que no fabrica reseñas ni redes de enlaces; un especialista en conversión que no afirma un resultado definitivo con una muestra insuficiente.

Podemos llamarlo capacidad de no actuar: reconocer los comportamientos que el sistema no debe realizar aunque técnicamente pueda.

Saber qué no puedes hacer es una cosa. Saber qué no debes hacer es otra.

El GBO incluye ambas en el contrato de capacidad.

El registro de capacidad legible por máquinas

Una página de servicios para personas tiene una narración natural. Los agentes pueden necesitar información más estructurada.

Los siguientes nombres de campos son ejemplos de diseño que muestran qué puede contener el registro. No se presentan como esquema de API ejecutable ni como estándar externo reconocido:

capability_name

provider_identity

outcome

supported_use_cases

unsupported_use_cases

required_inputs

eligibility

deliverables

quality_criteria

commercial_terms

third_party_costs

capacity_status

supported_languages

supported_regions

required_permissions

human_approval

evidence

version

valid_from

valid_until

failure_behavior

rollback

contact_or_action_endpoint

El registro no tiene que hacer públicos todos los detalles. Pero la información necesaria para el comportamiento del agente debe proporcionarse de forma coherente.

La regla más importante: el registro para máquinas no debe prometer más que la página de servicios visible.

Paridad entre capacidad visible y legible por máquinas

Si una página indica «Precio a solicitud», el registro no debe inventar una cifra.

Si la página dice «Solo para clientes existentes», el catálogo no debe presentar el servicio como disponible para todos.

Si dice «No se garantizan resultados», los datos estructurados no deben insinuar un resultado seguro.

Si dice «Requiere aprobación humana», la interfaz de acción no debe permitir la ejecución directa.

Podemos llamar a esta relación paridad de capacidad: la realidad del servicio que leen las personas debe coincidir con la realidad estructurada que utilizan los agentes.

La procedencia de la capacidad

Debe conocerse en qué se apoya la capacidad. ¿La empresa trabaja con equipos propios?

¿Utiliza subcontratistas?

¿Depende de una plataforma de terceros?

¿Utiliza herramientas de código abierto?

¿Opera un modelo con licencia?

¿Trabaja en los sistemas del cliente?

Todo ello puede explicarse sin revelar detalles de secretos comerciales.

Por ejemplo: «La voz puede generarse con herramientas de terceros con licencia una vez obtenidos los derechos necesarios y la aprobación escrita». La frase explica tanto la capacidad como su dependencia. El agente no presupone que el proveedor haya desarrollado todos los componentes.

Dependencia de terceros

Si un servicio depende de otros sistemas, quizá no controle por completo el resultado.

• Un proveedor de nube,
• un sistema de pagos,
• un buscador,
• una plataforma social,
• un proveedor de modelos,
• un servicio de licencias,
• o un proveedor de mapas o datos

puede sufrir interrupciones o cambiar sus reglas.

El contrato de capacidad debe indicar:

• qué dependencias hay,
• qué riesgos quedan fuera de control,
• y qué alternativa o plan de reversión existe,

en la medida de lo posible.

Depender del servicio de otro no invalida la capacidad. Ocultar esa dependencia vuelve engañosa su descripción.

¿Cómo sabemos si un servicio está preparado?

Puede considerarse preparado para la acción cuando:

• Su identidad está vinculada al proveedor correcto.
• El resultado está definido con claridad.
• Se conocen las entradas necesarias.
• El alcance incluido y excluido es visible.
• Se ha explicado el precio o cómo se determina.
• Se conocen los recursos disponibles y las condiciones de inicio.
• Las pruebas respaldan la afirmación dentro de sus límites.
• Los registros para personas y máquinas no se contradicen.
• La vía de operación o comunicación es segura.
• Se han definido la respuesta al fallo y la reversión.

Sin esas condiciones, el servicio puede ser visible, pero no está preparado para que un agente lo elija con seguridad.

La puerta de capacidad NOMOS

En el modelo de la puerta de capacidad NOMOS proponemos ocho áreas de examen. Las condiciones necesarias para la operación deben verificarse en ellas según el contexto y el riesgo:

1. Puerta del resultado

¿Está claro qué se va a producir?

2. Puerta de la prueba

¿La capacidad está respaldada por pruebas proporcionadas a la magnitud de la afirmación?

3. Puerta del alcance

¿Están definidas las inclusiones y exclusiones?

4. Puerta de las entradas

¿Se pueden aportar los datos, accesos, contribución humana y requisitos necesarios?

5. Puerta de los recursos disponibles

¿Puede el proveedor o agente hacer este trabajo ahora y a la escala necesaria?

6. Puerta comercial

¿Se entienden los precios, costos de terceros y obligaciones continuas?

7. Puerta de la ejecución

¿Hay una vía de operación segura para iniciar o utilizar el servicio?

8. Puerta del fallo

¿Hay un método para detener, transferir, revertir o reparar cuando surge un problema?

De forma simplificada:

CONDICIONES DE LA PUERTA DE CAPACIDAD:

RESULTADO CLARO

Y PRUEBA ADECUADA

Y ALCANCE CLARO

Y ENTRADAS SUFICIENTES

Y RECURSOS DISPONIBLES

Y CONDICIONES COMERCIALES COMPRENSIBLES

Y EJECUCIÓN SEGURA

Y PLAN ANTE EL FALLO

No es un sistema de suma de puntos. Si no se supera una puerta crítica, el agente no debe actuar directamente.

Cómo actuar ante una capacidad incompleta

¿Qué debe hacer el agente cuando falta información sobre una capacidad?

Hay tres opciones básicas:

Preguntar

«¿La migración de datos está incluida en el precio?» «¿Este paquete cubre la respuesta a incidentes en fin de semana?» «¿Se ofrecen solo contenidos en seis idiomas o también soporte en directo?»

Reducir el nivel de acción

Pedir una oferta en vez de comprar. Preparar una lista corta en vez de elegir directamente. Crear un entorno de pruebas en vez de publicar en producción.

Buscar otra opción

Si no se puede demostrar un requisito crítico, se puede buscar un proveedor más adecuado. El agente no debe rellenar por su cuenta la información que falta.

Ejemplo de un agente de compras

Una empresa quiere renovar sus presentaciones comerciales.

Encarga al agente: «Encuentra un proveedor de sistemas de presentaciones para directivos. Tenemos un presupuesto de 4.000 dólares y necesitamos la primera presentación para el consejo de administración en dos semanas». El agente encuentra tres proveedores.

Proveedor A

Sus imágenes son muy buenas. Afirma crear «presentaciones de nivel mundial». No explica precio, plazo ni responsabilidad sobre el contenido.

Proveedor B

Tiene una apariencia más sobria.

Explica:

• Narrativa estratégica
• Sistema de diapositivas
• Visualización de datos
• Archivos fuente
• Límite de revisiones definido
• Plazo del trabajo inicial
• Verificación del texto por parte del cliente
• Aprobación humana de afirmaciones jurídicas y financieras

Proveedor C

Vende plantillas existentes a bajo precio, pero no ofrece narrativa para directivos ni tratamiento de datos a medida. A puede ser más visible en buscadores. C puede parecer más asequible. B puede ser la opción adecuada para la necesidad real.

Pero antes de elegir B, el agente debe verificar:

• sus recursos disponibles,
• el plazo de dos semanas,
• el presupuesto de 4.000 dólares,
• y los datos que deben aportarse.

El contrato de capacidad permite pasar de la visibilidad a las condiciones reales de elección.

Ejemplo de un agente de IA

Una empresa busca un agente que gestione su correo.

Una página de producto dice «Gestión de correo totalmente autónoma». La frase impresiona.

Pero deben responderse estas preguntas:

• ¿Solo clasifica los mensajes entrantes?
• ¿Prepara borradores?
• ¿Envía automáticamente?
• ¿A quién puede enviar?
• ¿Cómo trata mensajes con precios, contratos o información jurídica?
• ¿Puede leer archivos adjuntos?
• ¿Adónde transfiere los datos personales?
• ¿Cómo se detiene un envío equivocado?
• ¿En qué punto hace falta aprobación humana?
• ¿Se registra la operación?

«Totalmente autónomo» no responde a estas preguntas. Sin límites claros puede crear expectativas falsas sobre la autorización del sistema. El contrato debe mostrar bajo qué condiciones actúa, no solo qué sabe hacer.

Capacidad y seguridad no están separadas

Si un sistema solo puede realizar una tarea en condiciones normales, su capacidad está incompleta. Importa cómo responde a un incidente de seguridad, una entrada errónea o un fallo de herramienta. ¿El agente de un portal de clientes distingue instrucciones maliciosas en lo que introduce el usuario?

¿Un agente de correo reconoce una solicitud de pago falsa?

¿Un sistema de avatares puede detener la generación de guiones no autorizados?

¿Un agente web verifica el alcance antes de modificar la web en producción?

¿Un agente de compras detecta una suscripción oculta o una renovación automática?

La seguridad no es un seguro añadido por fuera de la capacidad.

Una tarea que no puede hacerse con seguridad no constituye una capacidad completa.

Capacidad y accesibilidad

Un producto puede funcionar técnicamente sin ser utilizable por todas las personas. Pueden quedar fuera usuarios con distintas condiciones visuales, auditivas, motrices o cognitivas. Una experiencia web 3D puede funcionar solo en dispositivos potentes. La reproducción automática de una identidad sonora puede resultar molesta. Un video de avatar puede carecer de subtítulos. Un portal de clientes puede admitir solo el ratón. La accesibilidad también forma parte del contrato de capacidad.

Si un servicio dice «Creamos experiencias web»,

importa preguntar:

• ¿Hay una alternativa para dispositivos menos potentes?
• ¿Existe una experiencia 2D de respaldo?
• ¿Se puede utilizar con teclado?
• ¿Hay una preferencia para reducir el movimiento?
• ¿Se proporcionan subtítulos y transcripciones?

Producir un resultado solo para un usuario ideal reduce el alcance de la capacidad. Esa reducción debe mostrarse claramente.

Capacidad y límites jurídicos

Una empresa puede no dar asesoramiento jurídico y, aun así, prestar servicios con efectos jurídicos. Un avatar de IA afecta a derechos sobre rostro y voz. Un portal de clientes trata datos personales. Un trabajo de marca puede afectar a derechos sobre nombres y signos. La automatización del correo puede estar sujeta a reglas de comunicación comercial. El contrato de capacidad no tiene que atribuirse especialización jurídica.

Pero sí debe distinguir:

¿Qué controles técnicos u operativos incluye el servicio? ¿Qué evaluación jurídica corresponde al especialista del cliente?

Hay que tratar con cuidado afirmaciones como «Garantía de pleno cumplimiento normativo». Citar un estándar no constituye un certificado de conformidad jurídica.

¿Dónde termina un servicio y empieza otro?

Confundir servicios cercanos puede llevar a una mala elección.

Por ejemplo:

• SEO y GEO
• Hosting y operaciones web
• Logotipo e identidad visual
• Informes y sistemas de decisión
• Optimización de conversión y desarrollo de software
• Producción de avatares de IA y autorización de publicación empresarial
• Consultoría DevOps y gestión continua de infraestructura

El contrato de capacidad debe separar con claridad los servicios vecinos.

¿Dónde empieza este servicio? ¿Dónde termina? ¿En qué punto hace falta otro?

La distinción no sirve solo para fijar precios. Permite al agente construir la cadena de servicios adecuada.

Revisar el grado de preparación

Los cinco niveles del inicio del capítulo ayudan a evaluar el conjunto: capacidad declarada, explicada, demostrada, operativa y preparada para la acción. En el último no basta un resultado de muestra; también deben conocerse alcance actual, recursos disponibles, autorización y condiciones de operación. Los servicios de una organización no tienen que estar todos en el mismo nivel, pero el agente debe saber cuál ha alcanzado cada uno.

Quince preguntas para auditar la capacidad

Sobre un servicio, producto o agente se puede preguntar:

• ¿Qué resultado exacto se producirá?
• ¿Se distinguen el resultado y los entregables?
• ¿Están claras las entradas y los requisitos previos?
• ¿Se conoce el alcance incluido y excluido?
• ¿Hay pruebas actuales de la capacidad?
• ¿Las pruebas respaldan realmente la magnitud de la afirmación?
• ¿Se explican el método de fijación del precio y los costos adicionales?
• ¿Se conocen los recursos disponibles y la fecha de inicio?
• ¿Hay límites geográficos, lingüísticos, tecnológicos o sectoriales?
• ¿Los registros para personas y máquinas muestran la misma capacidad?
• ¿Se han explicado las dependencias de terceros?
• ¿Está definido qué se hará si algo falla?
• ¿Son visibles los resultados que no se garantizan?
• ¿La capacidad tiene versión y fecha de actualización?
• ¿Existe una vía segura y autorizada para iniciar el servicio?

Si la mayoría no tiene respuesta, quizá el servicio pueda venderse, pero no está preparado para que un agente lo elija con seguridad.

La utilidad del contrato de capacidad para las personas

No está pensado solo para máquinas. Busca reducir expectativas falsas y facilitar comparaciones. Un alcance, entregables y criterios de aceptación claros dan una base tanto a la conversación comercial como a la implementación. El registro también permite comprobar si distintos empleados describen de manera diferente el mismo servicio. No son resultados comerciales automáticos: la duración de las conversaciones, la proporción de solicitudes adecuadas y los conflictos deben medirse por separado. El servicio puede parecer adecuado para menos personas; lo importante es reconocer con más claridad las coincidencias correctas.

El valor comercial de explicar la capacidad

Algunas empresas creen que explicar límites proporciona información a los competidores. La ambigüedad también hace perder confianza.

La organización parece más profesional cuando clientes y agentes pueden responder fácilmente:

• ¿Qué recibo?
• ¿Qué no recibo?
• ¿Cuánto pagaré?
• ¿Qué debo aportar?
• ¿Cómo se verificará el resultado?
• ¿Qué ocurrirá si hay un problema?

Un competidor puede copiar las palabras.

Pero quizá no pueda copiar:

• la capacidad real de entrega,
• el sistema de pruebas,
• las pruebas del trabajo anterior,
• la disciplina operativa,
• la coherencia multilingüe,
• y el mecanismo de reversión

con la misma rapidez. Explicar la capacidad no es revelar todos los secretos. Es mostrar los hechos que el cliente necesita para decidir bien.

La frontera entre claridad y secreto comercial

Una empresa no tiene que publicar todos sus procesos internos.

Pueden seguir siendo confidenciales:

• Prompts propios
• Código fuente
• Ponderaciones de evaluación internas
• Análisis de competidores
• Detalles de seguridad
• El núcleo de automatización
• Precios de proveedores
• Instrucciones internas de agentes

Pero ocultar lo siguiente puede desviar el comportamiento:

• El alcance real del servicio
• Cómo se calcula el precio
• Exclusiones importantes
• La aprobación humana necesaria
• Los costos de terceros
• El límite de capacidad disponible
• Los resultados no garantizados
• La vía de retirada o cancelación

El principio es:

Puedes mantener en secreto el interior del motor. No puedes ocultar los límites de comportamiento que el usuario necesita para elegir con seguridad.

El comprobante de capacidad

Cuando un servicio o agente completa un resultado concreto, puede generar un registro llamado:

Comprobante de capacidad

En él queda constancia del trabajo realizado.

El registro muestra:

• ¿Qué capacidad se utilizó?
• ¿En qué versión?
• ¿Con qué entradas?
• ¿Bajo qué alcance?
• ¿Qué personas o agentes participaron?
• ¿Qué pruebas se hicieron?
• ¿Qué resultado se obtuvo?
• ¿Qué límites siguieron vigentes?
• ¿Qué problemas quedan abiertos?
• ¿Cuándo se produjo el resultado?
• ¿Hay una vía para revertirlo o corregirlo?

Vinculado a resultados verificables y pruebas realizadas, el registro puede servir de base a evaluaciones posteriores. Una declaración de éxito, por sí sola, no basta como prueba de capacidad. La idoneidad debe evaluarse de nuevo en cada situación. Haber tenido éxito no autoriza automáticamente todos los trabajos futuros.

¿Cómo debe prepararse una organización?

Si quiere mostrar sus capacidades con precisión en la era de los agentes, debe:

Crear un inventario de capacidades

Enumerar todos los servicios que realmente ofrece.

Separar los servicios vecinos

Distinguir los que se parecen pero tienen precios y responsabilidades diferentes.

Preparar un registro canónico de alcance

Definir para cada servicio qué se incluye y qué se excluye.

Explicar la relación con el precio

Diferenciar precios fijos, de partida, mensuales, anuales y a solicitud.

Vincular las pruebas

Respaldar las afirmaciones con ejemplos, pruebas, publicaciones o registros independientes adecuados.

Mantener actualizados los recursos disponibles

Seguir la aceptación de trabajo y las condiciones temporales.

Asegurar la paridad legible por máquinas

La página visible, el catálogo, el esquema, las preguntas frecuentes y las interfaces de operación no deben contradecirse.

Definir cómo responder a los fallos

¿Quién hará qué cuando surja un problema?

¿Cómo debe hablar el agente de una capacidad incierta?

No debe formular afirmaciones seguras sobre una capacidad que no conoce con certeza.

Incorrecto: «Esta empresa ofrece soporte completo a clientes en seis idiomas».

Más preciso: «La empresa publica contenido y páginas de servicios en seis idiomas; hay que verificar por separado los idiomas del soporte en directo».

Incorrecto: «Este paquete de hosting incluye soporte gestionado las veinticuatro horas».

Más preciso: «El paquete cubre hosting; la respuesta activa a incidentes y las operaciones gestionadas pueden ser servicios aparte».

Incorrecto: «Este sistema de avatares de IA cumple plenamente toda la legislación».

Más preciso: «El sistema define controles de consentimiento, información al usuario, procedencia y retirada; la conformidad jurídica debe evaluarse aparte según el país y el uso». Expresar honestamente la incertidumbre no debilita al agente: lo hace fiable.

Poder hacerlo de verdad

Para afirmar que una organización realmente puede hacer algo, no basta «Ya lo hemos hecho».

Una formulación más sólida es: «Podemos producir este resultado con estas entradas, dentro de este alcance, con estos controles de calidad y bajo estos límites. Aquí están las pruebas. En estas situaciones no aceptamos el servicio o pedimos aprobación humana». Es más larga, pero contiene la precisión que exige la era de los agentes.

La conclusión del capítulo

La identidad muestra con quién tratamos. La capacidad explica qué puede hacer realmente esa entidad.

Pero una capacidad no es:

• un eslogan,
• un logotipo tecnológico,
• un único caso de éxito,
• acceso a una herramienta,
• ni una afirmación comercial amplia.

La capacidad real reúne:

Resultado claro Entradas necesarias Pruebas verificables Alcance claro Recursos disponibles actuales Condiciones comerciales comprensibles Ejecución segura Respuesta al fallo

Una organización puede saber hacer el trabajo y no tener recursos ahora. Un agente puede utilizar la herramienta sin estar autorizado. Un servicio puede ser bueno y no ser adecuado para ese cliente. Un precio puede ser correcto y estar asociado al alcance equivocado. Una prueba puede ser real y no sostener una afirmación universal.

La segunda puerta del comportamiento en GBO es esta: no evalúes solo a quien dice «Puedo», sino a quien demuestra qué puede hacer y bajo qué condiciones. El contrato de capacidad NOMOS transforma la afirmación en una base real preparada para la acción.

Muestra al agente:

• qué es posible,
• qué no lo es,
• qué entradas necesita,
• qué límites existen,
• qué significa el precio,
• cuándo está vigente la capacidad,
• y qué ocurrirá si hay un error.

Aun así, conocer la identidad correcta y la capacidad demostrada no basta para elegir. Una empresa puede existir, ofrecer de verdad el servicio y explicar precio y recursos disponibles. Puede seguir siendo la opción equivocada para un usuario, propósito o riesgo concreto.

En el próximo capítulo abordaremos una de las preguntas más delicadas del GBO:

¿Cuándo debe elegirte un agente?

Ser el proveedor correcto no es lo mismo que ser elegido en todas las situaciones.

La capacidad te convierte en candidato. La idoneidad determina si la elección es realmente correcta.