Qué cuenta como evidencia de un AI component
Nota: Este documento es una traducción automática del original en inglés.
Qué cuenta como evidencia de un AI component
Cuando DecAIHub evalúa si un proyecto tiene un AI component funcional, busca artefactos verificables — no textos de marketing, no promesas, no asociaciones de marca. Esta página enumera los tipos de evidencia que refuerzan el eje de AI reality de la puntuación DecAI Fit, ordenados de más fuerte a más débil.
En resumen: la evidencia de IA son artefactos que puedes inspeccionar, probar o verificar de forma independiente — código, documentación, métricas con metodología, demos funcionales y evaluaciones de terceros.
Evidencia Tier-1 (la más fuerte)
Las fuentes Tier-1 son artefactos publicados o controlados por el propio proyecto. Para el eje de AI reality, la evidencia Tier-1 más fuerte incluye:
- Repositorio público con código de IA/ML — scripts de entrenamiento de modelos, lógica de inferencia, pipelines de datos, pasos de preprocesamiento. Un repositorio con commits, releases y tests es mucho más fuerte que un repo de marcador de posición con un README.
- Documentación técnica — descripciones de la arquitectura del modelo, formatos de entrada/salida, versiones del modelo e historial de actualizaciones. Esto responde a "qué modelo, cómo funciona y qué versión está en ejecución".
- Métricas de calidad con metodología — benchmarks publicados o resultados de evaluación que especifican qué se midió, con qué datos, cuándo y con qué versión del modelo. Las métricas sin este contexto no son evidencia.
- Demos o endpoints funcionales — una interfaz, API o sandbox accesible públicamente donde se pueda probar el AI component. Una demo que procesa entradas reales y devuelve salidas impulsadas por IA es evidencia directa.
- Informes de auditoría o evaluaciones de terceros — evaluaciones independientes de la calidad, equidad, seguridad o rendimiento del modelo por una entidad reconocida.
Patrones que refuerzan la evidencia Tier-1
No todos los artefactos Tier-1 son igual de convincentes. Varios patrones observables hacen que la evidencia sea más creíble:
- Profundidad del historial de commits. Un repositorio con meses o años de commits incrementales, pull requests, revisiones de código y releases versionadas demuestra un esfuerzo de ingeniería sostenido. Una única subida masiva tiene mucho menos peso.
- Cobertura de tests y pipelines de CI. Los tests automatizados para la inferencia del modelo, la validación de datos y los endpoints de integración indican un sistema de grado de producción en lugar de una prueba de concepto.
- Modelos versionados y changelogs. Cuando la documentación registra qué versión del modelo está desplegada, qué cambió entre versiones y por qué, señala un sistema vivo con un ciclo de desarrollo activo.
- Salidas reproducibles. Si una demo o API devuelve resultados consistentes y explicables para las mismas entradas a lo largo de las sesiones, esto es más fuerte que una exhibición puntual.
- Separación de la lógica de IA del boilerplate. Una base de código donde los módulos de IA/ML son claramente identificables — distintos del andamiaje del frontend, los scripts de despliegue o los contratos del token — facilita verificar qué hace realmente el AI component.
Evidencia Tier-2 (contexto, no prueba)
Las fuentes Tier-2 aportan contexto pero no prueban por sí solas un AI component funcional:
- Entrevistas o AMAs donde el equipo describe el enfoque de IA, la arquitectura o el proceso de entrenamiento.
- Descripciones de agregadores (CoinGecko, DeFiLlama, etc.) que mencionan capacidades de IA.
- Anuncios de asociación con proveedores de IA o laboratorios de investigación.
La evidencia Tier-2 puede respaldar un hallazgo Tier-1 pero no puede reemplazarlo. Una asociación con una empresa de IA no prueba que el proyecto tenga su propia IA funcional.
Cuándo importa la evidencia Tier-2
Las fuentes Tier-2 se vuelven relevantes cuando corroboran artefactos Tier-1 o cubren vacíos que el Tier-1 por sí solo deja ambiguos:
- Una entrevista técnica donde el equipo recorre la arquitectura descrita en su documentación añade credibilidad a los documentos Tier-1.
- Un listado de agregador que coincide con las capacidades descritas en el propio whitepaper del proyecto señala consistencia.
- Una charla de conferencia con una demo en vivo que refleja el comportamiento de la API pública del proyecto refuerza que la demo no está guionizada.
Sin embargo, sin artefactos Tier-1 subyacentes, incluso las fuentes Tier-2 más convincentes siguen siendo contexto — valiosas para la comprensión, insuficientes para la verificación.
Qué no cuenta
Algunos artefactos parecen evidencia pero no demuestran un AI component funcional. Las señales falsas comunes incluyen textos de marketing, repositorios vacíos, métricas sin metodología y API wrappers sin lógica propietaria. Para una lista detallada, consulta Qué no cuenta como evidencia de IA.
Cómo registra DecAIHub la evidencia de IA: banderas AI_0 a AI_4
El eje de AI reality usa cinco banderas binarias para capturar qué evidencia se ha encontrado:
| Bandera | Qué comprueba | Valor |
|---|---|---|
| AI_0 | ¿Hay al menos una declaración Tier-1 de intención de IA (roadmap, actualización oficial)? | 1 / 0 |
| AI_1 | ¿Hay una descripción de lo que hace la IA? | 1 / 0 |
| AI_2 | ¿Hay demos o ejemplos funcionales? | 1 / 0 |
| AI_3 | ¿Hay métricas de calidad con contexto (qué, con qué datos, cuándo)? | 1 / 0 |
| AI_4 | ¿Hay una descripción técnica, arquitectura o versiones de modelo? | 1 / 0 |
Cuantas más banderas sean iguales a 1, mayor es el ai_score y mejor el DecAI Fit del proyecto. Si ninguna de las banderas está activada, ai_score = 0 y DecAI Fit no puede superar 0.
Cómo las combinaciones de banderas se asignan a la confianza
Las banderas individuales responden preguntas acotadas, pero su combinación pinta un cuadro más completo:
| Banderas activadas | Interpretación típica |
|---|---|
| Solo AI_0 | Intención declarada; sin IA funcional verificada todavía |
| AI_0 + AI_1 | IA descrita con palabras; sin demo, sin métricas, sin arquitectura |
| AI_0 + AI_1 + AI_2 | Existe una demo funcional; aún sin métricas ni profundidad técnica |
| AI_0 + AI_1 + AI_2 + AI_4 | Demo y arquitectura presentes; falta la medición de calidad |
| Las cinco (AI_0 a AI_4) | El perfil de evidencia más fuerte: intención, descripción, demo, métricas y arquitectura |
Un proyecto no necesita satisfacer las cinco banderas para recibir un ai_score distinto de cero. Incluso AI_0 sola (intención con una fuente Tier-1) establece ai_score = 1. Sin embargo, las banderas superiores contribuyen a un techo más alto para el DecAI Fit.
Por qué la metodología importa para las métricas
Un número aislado — "95% de precisión", "baja latencia", "estado del arte" — no es evidencia sin contexto. DecAIHub considera las métricas significativas solo cuando responden a cuatro preguntas: qué se midió (precisión, F1, latencia, perplejidad), con qué datos (benchmark público, conjunto de prueba propietario, tráfico de producción), cuándo (fecha de la evaluación) y qué versión del modelo produjo el resultado. Sin esto, una métrica es una afirmación, no evidencia.
La prueba de las cuatro preguntas
Al evaluar cualquier métrica publicada, aplica este checklist:
- Qué — ¿La métrica está nombrada y definida? "Precisión" es ambiguo; "top-1 classification accuracy" es específico.
- Con qué datos — ¿Está identificado el dataset de evaluación? Un benchmark público permite la reproducción independiente; un conjunto de prueba propietario no, pero nombrarlo es mejor que el silencio.
- Cuándo — ¿Hay una fecha o etiqueta de release? Los modelos cambian con el tiempo; una métrica sin marca temporal puede no reflejar el sistema actual.
- Qué versión — ¿Se indica la versión del modelo o sistema? Si un proyecto ha lanzado múltiples iteraciones de modelo, la métrica debe estar ligada a una específica.
Si falta cualquiera de estas cuatro, la métrica cae de "evidencia" a "afirmación" en la evaluación de DecAIHub. Puede seguir apareciendo en la ficha del proyecto como una afirmación anotada, pero no contribuirá a establecer la bandera AI_3 en 1.
Cómo usar este checklist
Al leer la ficha de un proyecto, comprueba si la tabla de Evidencia referencia artefactos de la lista Tier-1 anterior. Si la ficha muestra ai_score = 0 o señala una preocupación de AI-washing, significa que estos artefactos no se encontraron a fecha de la verificación — esto no es una acusación contra el proyecto.
Cuando aparecen nuevos artefactos Tier-1, la ficha se actualiza y la puntuación puede cambiar.
Pasos prácticos para los lectores
- Empieza por la tabla de Evidencia. Busca enlaces a repositorios, documentación o demos. Si la tabla de Evidencia está vacía o referencia solo fuentes Tier-2/3, la afirmación de AI reality no está verificada.
- Haz clic en los artefactos. Un enlace a un repositorio es tan bueno como lo que hay dentro. Ábrelo y busca código de IA/ML, no solo un README o scripts de despliegue.
- Comprueba la fecha de verificación. La evidencia es una instantánea. Una ficha verificada hace seis meses puede no reflejar el estado actual del proyecto, por lo que DecAIHub aplica una penalización por obsolescencia tras 550 días.
- Coteja con la lista de antipatrones. Si ves patrones de Qué no cuenta como evidencia de IA, pondera la evidencia en consecuencia.
Qué no demuestra este checklist por sí solo
- Satisfacer todos los criterios de evidencia no demuestra que la IA sea de alta calidad o útil para los usuarios finales. Demuestra que existen artefactos y que pueden inspeccionarse.
- La evidencia Tier-1 del propio proyecto no demuestra independencia. Los datos autoinformados deberían idealmente corroborarse con una evaluación de terceros.
- Un registro de evidencia completo no demuestra que el token sea necesario. La AI reality es un eje de DecAI Fit; la token necessity es otro.
Preguntas frecuentes
¿Qué cuenta como la evidencia más completa de IA en un proyecto cripto?
Un repositorio público que contiene código de IA/ML con un historial de commits significativo, combinado con métricas de calidad publicadas que incluyen la metodología completa (qué se midió, con qué datos, cuándo y qué versión del modelo). Cuando ambos existen y se respaldan con una demo o un endpoint de API funcional, el perfil de evidencia está en su punto más completo. Ningún artefacto único es definitivo por sí solo — la combinación de código, métricas y salidas comprobables es lo que distingue la IA verificada de las afirmaciones no verificadas.
¿Puede un proyecto tener IA real sin código open-source?
Sí. El código open-source es la forma de evidencia más transparente, pero no la única. Un proyecto puede demostrar IA mediante documentación técnica detallada, benchmarks publicados con metodología, APIs funcionales que devuelven salidas impulsadas por IA verificables, o evaluaciones independientes de terceros. Sin embargo, sin al menos algún artefacto inspeccionable — código, demo o evaluación — no hay nada que DecAIHub (ni nadie más) pueda verificar. Cuanto más cerrado es un proyecto, más depende de la corroboración Tier-2 (entrevistas, datos de agregadores, demostraciones en conferencias) para construir credibilidad.
¿Una demo funcional demuestra que la IA es real?
Una demo funcional es evidencia fuerte, pero no es una prueba concluyente por sí misma. Un frontend bien diseñado puede simular un comportamiento de tipo IA usando respuestas codificadas (hardcoded), resultados precalculados o llamadas ocultas a una API de terceros. DecAIHub trata las demos como evidencia más fuerte cuando van acompañadas de documentación de API, identificadores de versión del modelo o salidas reproducibles a lo largo de distintas entradas. Una demo que acepta entradas arbitrarias del usuario y devuelve salidas variadas y contextualmente apropiadas es más convincente que una exhibición guiada con ejemplos predeterminados.
¿Cuál es la evidencia mínima necesaria para un ai_score distinto de cero?
El mínimo es una declaración Tier-1 de intención de IA — una entrada de roadmap, una entrada de blog oficial o una página de documentación que indique explícitamente planes relacionados con la IA. Esto establece la bandera AI_0 en 1 y produce ai_score = 1. Aunque esta es la puntuación más baja posible distinta de cero, distingue a los proyectos que se han comprometido oficialmente con una dirección de IA de los que no han mencionado la IA en absoluto. Para alcanzar puntuaciones más altas, el proyecto necesita aportar artefactos adicionales: descripciones del AI component (AI_1), demos (AI_2), métricas con metodología (AI_3) y detalles de arquitectura técnica (AI_4).
Referencias externas
- CommonMark specification — el estándar de marcado usado en todas las páginas wiki de DecAIHub, incluidas las fichas de proyectos y los explainers.
- Model Cards for Model Reporting (Mitchell et al., 2019) — un marco fundacional para documentar el rendimiento, el uso previsto y las limitaciones de los modelos de IA; estrechamente alineado con los principios de transparencia detrás de los criterios de evidencia de DecAIHub.
- NIST AI Risk Management Framework — un marco del gobierno de EE. UU. para identificar y gestionar los riesgos de la IA, incluida orientación sobre documentación, pruebas y metodología de evaluación.
No comments to display
No comments to display