La auditoría comprueba afirmaciones concretas sobre funciones e integraciones de tu SaaS. Parte de documentación vigente, plan, versión y fecha. Compara manualmente las respuestas: una mención de marca o una cita de documentación no demuestran exactitud.
Divide cada respuesta en afirmaciones individuales. «La integración lee datos y publica cambios automáticamente» contiene dos afirmaciones. Distingue lectura y escritura, operaciones manuales y automáticas, y creación de borradores y publicación.
La falta de documentación significa no verificado, no demuestra que una función no exista. Una afirmación incorrecta exige pruebas que la contradigan o confirmación del responsable de producto. Evalúa omisiones respecto al alcance previsto del test.
Registro de verificación manual
| Afirmación de IA | Fuente / versión / plan | Evaluación |
|---|---|---|
| Confirmada por documentación vigente | Misma función y plan | Correcta |
| Contradice el estado del producto | Prueba o confirmación del responsable | Incorrecta |
| Sin información concluyente | Consultar al equipo de producto | No verificada |
| Falta información esperada | Alcance previamente definido | Omitida |
Conserva recuentos por categoría. Si calculas exactitud, indica el denominador y los casos sin resolver por separado. No los cuentes automáticamente como correctos. Es una evaluación manual, distinta de las métricas de visibilidad de Semly.
Cómo auditar funciones e integraciones de un SaaS en la IA: método en 7 pasos
Los benchmarks generales de alucinación no sirven para auditar atributos de producto. Un modelo puede obtener una puntuación aceptable en conocimiento factual amplio y, al mismo tiempo, afirmar que tu SaaS incluye una integración con una herramienta que nunca existió, o que un plan de pago incluye una función reservada al plan enterprise. La razón es metodológica: los benchmarks miden conocimiento general, no la correspondencia entre lo que un modelo afirma sobre un producto concreto y lo que ese producto hace.
El método que sigue es un marco operativo completo. Antes de medir nada, define la verdad de referencia: la fuente canónica del producto contra la que compararás cada respuesta. Sin ese paso, cualquier auditoría produce datos no interpretables.
| Paso | Entregable | Tiempo estimado |
|---|---|---|
| 1. Verdad de referencia | Inventario versionado de funciones, integraciones, planes y límites | 2-4 h |
| 2. Clasificación del error | Taxonomía alucinación vs. obsolescencia | 1 h |
| 3. Muestreo de prompts | Plantilla por categoría y plan de repeticiones | 2-3 h |
| 4. Auditoría multi-modelo | Registro prompt / modelo / respuesta / veredicto | 3-6 h |
| 5. Priorización | Matriz impacto × frecuencia | 1-2 h |
| 6. Corrección | Acciones por tipo de error (schema, docs, contenido) | Variable |
| 7. Verificación | Comparación antes/después y re-muestreo | Continuo |
Paso 1 — Define la verdad de referencia del producto
La verdad de referencia es la única fuente autorizada sobre lo que tu producto hace. No es la web de marketing ni una nota de prensa antigua: es el inventario operativo que tu equipo de producto reconoce como correcto. Todo lo que la IA afirme se compara contra ese documento, no contra la intuición.
El inventario debe cubrir cuatro bloques: funciones, integraciones, planes y límites. Para cada elemento, registra los campos mínimos que permiten decidir si una respuesta de la IA es correcta, obsoleta o inventada.
Checklist de campos por elemento:
- Nombre canónico de la función o integración.
- Estado: activo, en beta, deprecado o retirado.
- Plan o nivel en el que está disponible.
- Límites aplicables (cuotas, volumen, regiones, idiomas).
- Fecha del último cambio de estado.
- Responsable interno que mantiene el dato.
Dos decisiones importan aquí. La primera: una sola fuente autorizada, versionada, con fecha de última revisión. La segunda: un propietario claro. Si el inventario lo mantienen tres equipos con criterios distintos, la auditoría heredará esa ambigüedad. En la práctica, la mayoría de las discrepancias entre lo que dice la IA y lo que hace el producto se resuelven en este paso, antes de tocar ningún prompt.
Paso 2 — Distingue alucinación de obsolescencia
No todos los errores son iguales y no se corrigen igual. La distinción crítica es entre alucinación y obsolescencia.
La consecuencia práctica: si tratas la obsolescencia como alucinación, invertirás esfuerzo en "corregir" al modelo cuando el problema real es que tu documentación pública no refleja el estado actual del producto.
Paso 3 — Diseña el muestreo de prompts
Una auditoría no es preguntar una vez a ChatGPT. Es un muestreo reproducible. La variabilidad entre modelos, versiones y parámetros es alta: el mismo prompt produce respuestas distintas según el modelo, la versión y la temperatura. Por eso necesitas repeticiones y control de parámetros.
Recomendaciones operativas:
- Cubre las cinco categorías de atributos: funciones, integraciones, precios, límites y comparativas.
- Repite cada prompt varias veces por modelo para capturar la varianza natural de la generación.
- Registra la temperatura y los parámetros usados; sin ellos, los resultados no son comparables.
- Fija una frecuencia de re-muestreo (por ejemplo, mensual o tras cada release relevante) para detectar regresiones.
Plantilla de prompts por categoría:
- Funciones: "¿Qué funciones incluye [producto] en el plan [X]?" / "¿[producto] permite [función concreta]?"
- Integraciones: "¿Con qué herramientas se integra [producto]?" / "¿[producto] tiene integración nativa con [plataforma]?"
- Precios: "¿Cuánto cuesta [producto]?" / "¿Qué incluye el plan más económico de [producto]?"
- Límites: "¿Cuál es el límite de [recurso] en [producto]?" / "¿[producto] funciona en [región o idioma]?"
- Comparativas: "¿[producto] o [alternativa]? ¿Cuál tiene [función]?"
Paso 4 — Ejecuta la auditoría multi-modelo
Un solo modelo no representa el comportamiento del ecosistema. La cobertura debe incluir ChatGPT, Gemini, Claude, Google AI y Grok, porque cada uno tiene fuentes, versiones y comportamientos distintos. Auditar solo un modelo produce una foto parcial que no refleja lo que verá un comprador que consulte en otra herramienta.
Para cada ejecución, registra: prompt, modelo, versión, fecha, parámetros y veredicto (correcto, obsoleto, inventado, ambiguo). Ese registro es lo que convierte una colección de capturas en datos auditables.
Plantilla de registro:
| Prompt | Modelo | Versión | Fecha | Respuesta (resumen) | Veredicto |
|---|---|---|---|---|---|
| ¿[producto] se integra con [plataforma]? | ChatGPT | [versión] | [fecha] | Afirma integración nativa | Inventado |
| ¿Qué incluye el plan [X]? | Gemini | [versión] | [fecha] | Describe función retirada | Obsoleto |
Paso 5 — Clasifica y prioriza los errores
No todos los errores merecen la misma urgencia. Prioriza con tres criterios: impacto en preventa (¿el error bloquea una decisión de compra?), frecuencia (¿aparece en muchos prompts y modelos?) y riesgo reputacional (¿afecta a confianza o cumplimiento?).
La matriz impacto × frecuencia ordena la acción:
| Frecuencia baja | Frecuencia alta | |
|---|---|---|
| Impacto alto | Corregir pronto | Corregir de inmediato |
| Impacto bajo | Monitorizar | Corregir por lotes |
Un error de alto impacto y alta frecuencia típico es atribuir una función de seguridad o cumplimiento a un plan que no la incluye. Un error de bajo impacto y baja frecuencia puede ser una imprecisión menor en una descripción secundaria. La regla es simple: primero lo que un comprador vería antes de decidir.
Paso 6 — Corrige con datos estructurados y contenido canónico
Acciones por tipo de error:
- Alucinación: publicar documentación canónica explícita que defina la función o integración, con datos estructurados que la identifiquen sin ambigüedad.
- Obsolescencia: actualizar la documentación oficial, marcar el estado deprecado y generar contenido citable reciente que refleje el estado actual.
- Ambigüedad: unificar las descripciones de planes y límites en una sola fuente consistente, eliminando contradicciones entre páginas.
Paso 7 — Verifica y re-mide
Corregir sin re-medir es una apuesta. La verificación exige re-muestreo periódico y comparación antes/después con la misma metodología. Una advertencia metodológica: evaluar los efectos a los pocos días puede ser prematuro. Los modelos actualizan fuentes y comportamientos con ritmos distintos, y una mejora temprana no siempre se consolida.
Errores más frecuentes y cómo corregirlos
Semly permite consultar respuestas de IA y fuentes. Una persona conocedora del producto evalúa funciones e integraciones.
