Puntos clave
- AMSTAR-2 identifica 16 dominios de calidad metodológica; los errores más frecuentes en revisiones rechazadas se concentran en 7 de esos dominios, especialmente en los considerados críticos.
- El error más recurrente —y el más fácil de evitar— es no registrar protocolo antes del cribado. Aparece en el 60-70 % de las revisiones evaluadas con AMSTAR-2 con calificación baja.
- Los errores no se distribuyen al azar: hay una secuencia causal donde un protocolo débil produce criterios vagos, criterios vagos producen cribado inconsistente, y cribado inconsistente produce conclusiones no respaldadas.
- La mayoría de los errores se previenen con tres decisiones operativas: registrar protocolo, usar al menos dos revisores en cribado y elegir herramientas que fuerzan el registro de razones de exclusión.
- Los revisores editoriales de revistas top miran primero el diagrama PRISMA y el protocolo registrado; si alguno de los dos tiene problemas, la revisión rara vez supera el primer filtro.
Por qué este artículo importa más que un manual de buenas prácticas
Los manuales de revisión sistemática listan qué debe hacerse: registrar protocolo, doble revisor, evaluar riesgo de sesgo, reportar siguiendo PRISMA 2020. Eso ya se sabe. Lo que rara vez se explica con la misma claridad es qué errores cometen las revisiones cuando lo hacen mal: dónde fallan, por qué fallan, y qué cambio operativo concreto evita cada falla.
Este artículo está construido al revés de los manuales. En lugar de listar lo que hay que hacer, lista lo que sale mal —en revisiones reales evaluadas con AMSTAR-2, en informes editoriales de revistas top y en defensas de tesis—. Para cada error, identifica la causa raíz y la decisión operativa que lo previene. La lista de 10 no es arbitraria: refleja los problemas que reaparecen en evaluaciones críticas año tras año.
Error 1 — Definir criterios de inclusión después de ver la búsqueda
Por qué pasa
El equipo lanza una búsqueda preliminar para "explorar el campo", ve qué tipo de estudios aparecen y redacta los criterios de inclusión a partir de lo que encontró. Aparentemente es eficiente: los criterios resultan factibles porque están calibrados con la realidad de la literatura disponible. Pero introduce un sesgo de confirmación retrospectivo difícil de detectar desde fuera.
Ejemplo
Una revisión sobre eficacia de la terapia X en una condición Y arranca con búsqueda preliminar, encuentra 30 estudios, observa que la mayoría con resultados positivos tienen seguimiento corto y los con resultados negativos seguimiento largo, y redacta criterios que aceptan solo seguimientos cortos "para mantener homogeneidad". Resultado: revisión positiva por construcción.
Cómo evitarlo
Registrar protocolo en PROSPERO antes de iniciar la búsqueda formal. Los criterios deben formularse a partir de la pregunta PICO, no de la literatura. Para guiar la redacción, 12 ejemplos de preguntas PICO por disciplina y la guía operacional de criterios de inclusión y exclusión muestran el nivel de especificidad que protege contra este error.
Cómo lo previene SynthIA
El protocolo se captura como configuración del proyecto al inicio. Los criterios de elegibilidad quedan registrados con fecha y no se pueden modificar silenciosamente: cualquier cambio queda en el historial del proyecto.
Error 2 — Buscar en una sola base de datos
Por qué pasa
Pereza o restricciones de acceso. Muchas revisiones se limitan a PubMed o Scopus porque son las bases que el equipo conoce. Para preguntas biomédicas centradas en literatura indexada en MEDLINE, parece suficiente. No lo es.
Ejemplo
Una revisión sobre intervenciones de enfermería en cuidados paliativos buscada solo en PubMed pierde sistemáticamente literatura en CINAHL (base especializada en enfermería) y en bases regionales (LILACS, SciELO). El resultado es una revisión sesgada hacia la perspectiva biomédica anglosajona.
Cómo evitarlo
Buscar en al menos dos bases generales (PubMed, Scopus, Web of Science u OpenAlex) más una especializada según área (CINAHL para enfermería, PsycINFO para psicología, ERIC para educación) más al menos una de literatura gris (registros de ensayos, tesis, OpenGrey). Para comparar el alcance de las bases principales, OpenAlex frente a PubMed detalla qué cubre cada una.
Cómo lo previene SynthIA
La integración nativa con OpenAlex permite cubrir un universo amplio de revistas en una sola búsqueda, complementable con importación de exportaciones de PubMed, Scopus o bases regionales sin manipulación manual.
Error 3 — Cribar con un solo revisor sin justificación
Por qué pasa
Restricciones de personal. Una tesis individual o un equipo pequeño asume que el doble cribado es opcional o que basta con que un segundo revisor verifique una muestra después.
Ejemplo
Un tesista de doctorado criba 4.000 artículos solo en título y resumen. Su director "valida" una muestra del 10 % al final. El director encuentra acuerdo del 92 % en la muestra y se asume que el cribado es válido. Pero el 8 % de discordancia extrapolado al total significa 320 decisiones cuestionables; algunas de ellas pueden ser estudios clave perdidos.
Cómo evitarlo
Al menos dos revisores independientes en la fase de texto completo, idealmente también en título y resumen. Si las restricciones imposibilitan el doble cribado completo, declarar explícitamente la limitación en el protocolo y en el manuscrito. La guía sobre cribado doble revisor con kappa de Cohen cubre los modelos de solapamiento total y parcial.
Cómo lo previene SynthIA
El cribado doble ciego es nativo: cada revisor ve los artículos sin conocer la decisión del otro, las discordancias se marcan automáticamente y el kappa se calcula en tiempo real.
Error 4 — No tener protocolo previo o no registrarlo
Por qué pasa
Desconocimiento o desidia. Algunos equipos consideran que el protocolo es burocracia. Otros lo redactan pero no lo registran en PROSPERO porque no quieren "complicar" el cronograma. AMSTAR-2 considera el protocolo registrado como uno de los siete ítems críticos: sin él, la calificación no puede ser alta.
Ejemplo
Una revisión publicada en una revista mediana sin registro PROSPERO. Cuando un meta-revisor la evalúa con AMSTAR-2 dos años después, la califica como "criticalmente baja" por ausencia de protocolo, independientemente de que la metodología sea técnicamente correcta. Esa revisión deja de citarse como evidencia válida en otras síntesis.
Cómo evitarlo
Registrar en PROSPERO antes de iniciar el cribado. La aprobación tarda entre una y cuatro semanas. Para protocolos en áreas no biomédicas, alternativas válidas son OSF Registries, INPLASY o el registro institucional con fecha verificable. Para el detalle paso a paso, cómo registrar en PROSPERO y cómo escribir el protocolo cubren respectivamente el formulario y la redacción.
Cómo lo previene SynthIA
El proyecto se inicia con los campos del protocolo capturados como configuración, lo que produce un protocolo exportable listo para registrar en PROSPERO sin trabajo duplicado.
Error 5 — Omitir la literatura gris
Por qué pasa
La literatura gris (tesis, informes técnicos, actas de congreso, preprints, registros de ensayos clínicos) es difícil de buscar sistemáticamente. Las bases tradicionales no la cubren bien. Excluirla parece más limpio.
Ejemplo
Una revisión que excluye literatura gris sistemáticamente sobreestima el efecto de la intervención porque los estudios con resultados negativos suelen quedarse en tesis no publicadas o congresos. Es el sesgo de publicación operando en sentido contrario: si solo miras lo publicado en revistas, miras una muestra sesgada.
Cómo evitarlo
Incluir explícitamente en la estrategia de búsqueda: registros de ensayos (ClinicalTrials.gov, WHO ICTRP), bases de tesis (ProQuest, repositorios institucionales), preprints (medRxiv, bioRxiv, SSRN) y literatura gris general (OpenGrey, Google Scholar para detección con verificación posterior). Declarar lo que se incluyó y lo que no.
Error 6 — Deduplicación deficiente
Por qué pasa
La deduplicación manual con hojas de cálculo o con la función básica de Zotero/EndNote pierde duplicados con variaciones menores en metadatos. El mismo estudio puede aparecer dos veces y contarse como dos en el diagrama PRISMA, inflando artificialmente los números.
Ejemplo
Una revisión que reporta 8.412 registros iniciales después de deduplicar. Una auditoría detecta que 340 son duplicados no detectados por variaciones de transliteración en autores asiáticos, por publicación en preprint y en revista, o por diferencias mínimas en título. Los números del diagrama PRISMA son incorrectos y la búsqueda parece más exhaustiva de lo que fue.
Cómo evitarlo
Combinar deduplicación automática (coincidencia exacta de DOI, título-autor-año) con deduplicación asistida (similaridad semántica para detectar duplicados con variaciones menores) y revisión humana de los pares marcados como sospechosos.
Cómo lo previene SynthIA
La deduplicación combina coincidencia exacta con detección semántica. Los duplicados detectados se presentan para confirmación humana y el conteo final del diagrama PRISMA se calcula automáticamente.
Error 7 — No registrar razones de exclusión en texto completo
Por qué pasa
Algunos equipos excluyen artículos en la fase de texto completo sin registrar la razón específica, asumiendo que basta con la decisión binaria. PRISMA 2020 ítem 17 lo prohíbe explícitamente: las exclusiones en texto completo deben aparecer con razones desglosadas en el diagrama final.
Ejemplo
Un revisor editorial recibe el manuscrito y mira el diagrama PRISMA: 320 artículos excluidos en texto completo, sin desglose de razones. El revisor pide la lista completa de artículos excluidos con razones individuales como condición de continuar la evaluación. El equipo se da cuenta de que tendrá que reconstruir esa información a posteriori, con el riesgo de inconsistencias.
Cómo evitarlo
Definir las categorías de razones de exclusión en el protocolo, alineadas con los criterios de elegibilidad. Forzar el registro de la razón en cada exclusión de texto completo. La herramienta que se use debería hacer imposible excluir sin razón asignada.
Cómo lo previene SynthIA
En la fase de texto completo, el sistema requiere asignar una categoría de razón de exclusión antes de cerrar la decisión. La lista de categorías se define al configurar el proyecto a partir de los criterios de elegibilidad.
Error 8 — Generar diagrama PRISMA inconsistente o ausente
Por qué pasa
El diagrama PRISMA 2020 es laborioso si se construye manualmente: hay que contar registros por fase, asegurarse de que los números cierran (cada artículo termina en una celda y solo una), incluir el desglose de razones de exclusión en texto completo. Muchos equipos hacen el diagrama al final con números que no coinciden exactamente con los registros operacionales.
Ejemplo
Un manuscrito presenta diagrama PRISMA con 4.250 registros tras deduplicación, 4.100 excluidos en título/resumen, 150 evaluados en texto completo y 28 incluidos. Suma: 4.100 + 150 = 4.250 (correcto). Pero los 150 evaluados en texto completo se desglosan así: 28 incluidos + 95 excluidos (con razones) = 123. Faltan 27 artículos. El revisor pide aclaración y el equipo no puede reconstruir adónde fueron esos 27.
Cómo evitarlo
El diagrama PRISMA debe generarse a partir de los registros operacionales del proyecto, no reconstruirse manualmente al final. Cada artículo debe estar etiquetado con su fase final y, si fue excluido en texto completo, con su razón. La guía sobre cómo crear el diagrama de flujo PRISMA detalla la estructura de cada celda.
Cómo lo previene SynthIA
El diagrama PRISMA 2020 se genera automáticamente con todas las celdas pobladas a partir del estado actual del proyecto. Los números siempre cierran porque salen del mismo origen de datos.
Error 9 — No evaluar riesgo de sesgo o usar herramienta equivocada
Por qué pasa
La evaluación de riesgo de sesgo se posterga al final y se hace deprisa. A veces se aplica una herramienta inadecuada al tipo de estudio (RoB 2 a estudios observacionales, por ejemplo) o se hace por un solo revisor sin doble verificación.
Ejemplo
Una revisión sobre eficacia de una intervención educativa incluye 15 ECAs y 12 estudios observacionales. El equipo aplica RoB 2 a los 27 estudios. RoB 2 está diseñado para ECAs; aplicarlo a estudios observacionales produce evaluaciones sin sentido metodológico. El revisor editorial detecta el error y pide rehacer la evaluación de los 12 observacionales con ROBINS-I.
Cómo evitarlo
Elegir la herramienta apropiada según diseño: RoB 2 para ECAs, ROBINS-I para estudios observacionales de intervenciones, QUADAS-2 para estudios de exactitud diagnóstica, ROBIS para revisiones sistemáticas previas (si la tuya es una umbrella review). Hacer la evaluación con doble revisor independiente. La guía sobre evaluación de riesgo de sesgo con RoB 2 detalla los dominios.
Error 10 — Conclusiones no respaldadas por la evidencia sintetizada
Por qué pasa
Las conclusiones se redactan con el lenguaje del equipo sobre el tema, no con el lenguaje estricto de la evidencia. Una revisión que encuentra evidencia de certeza moderada-baja con tamaños de efecto pequeños concluye que "la intervención es eficaz y debería recomendarse en la práctica clínica". La afirmación va más allá de lo que los datos respaldan.
Ejemplo
Una revisión incluye 8 ECAs, dos de ellos con bajo riesgo de sesgo y seis con preocupaciones serias. El efecto pool es estadísticamente significativo pero pequeño, con I² de 65 % (heterogeneidad alta). La conclusión escrita: "la intervención X es eficaz para la condición Y". La conclusión soportada por la evidencia: "hay evidencia de certeza baja, con heterogeneidad alta entre estudios, que sugiere un efecto pequeño de la intervención X sobre Y; se requieren estudios adicionales con menor riesgo de sesgo antes de recomendar su uso rutinario".
Cómo evitarlo
Aplicar GRADE de forma sistemática para cada outcome y traducir el resultado en lenguaje calibrado. Las conclusiones deben mencionar explícitamente la certeza de la evidencia y la magnitud del efecto. Si la evidencia es de baja certeza, decirlo. Si la heterogeneidad es alta y limita la interpretación, decirlo. Para el contexto sobre cuándo el metaanálisis es apropiado y cuándo no, metaanálisis frente a revisión sistemática aclara la diferencia.
Resumen: los 10 errores y su solución operativa
| # | Error | Causa raíz | Solución operativa |
|---|---|---|---|
| 1 | Criterios definidos después de ver la búsqueda | Sin protocolo previo | Registrar protocolo en PROSPERO antes de buscar |
| 2 | Buscar en una sola base | Conveniencia | Mínimo 2 bases generales + 1 especializada + literatura gris |
| 3 | Cribado por un solo revisor | Restricciones de personal | Doble revisor al menos en texto completo |
| 4 | Sin protocolo registrado | Desconocimiento | Registro en PROSPERO, OSF o equivalente |
| 5 | Omitir literatura gris | Dificultad de búsqueda | Incluir registros de ensayos, tesis, preprints |
| 6 | Deduplicación deficiente | Herramientas básicas | Combinar deduplicación exacta + semántica |
| 7 | Sin razones de exclusión registradas | Flujo manual | Forzar registro categorizado en texto completo |
| 8 | Diagrama PRISMA inconsistente | Reconstrucción manual al final | Generación automática desde registros operacionales |
| 9 | Riesgo de sesgo mal evaluado | Herramienta incorrecta o un solo revisor | RoB 2/ROBINS-I/QUADAS-2 según diseño, doble revisor |
| 10 | Conclusiones no respaldadas | Lenguaje no calibrado | GRADE por outcome y traducción al lenguaje del informe |
La secuencia causal de los errores
Los 10 errores no son independientes. Hay una secuencia causal donde un error previo amplifica los siguientes.
Sin protocolo registrado (error 4) → los criterios pueden ser ajustados a posteriori (error 1) → la búsqueda no se valida frente a criterios estables (error 2) → la deduplicación es manual sin parámetros definidos (error 6) → el cribado se hace sin doble revisor (error 3) y sin registro de razones (error 7) → el diagrama PRISMA se reconstruye al final con inconsistencias (error 8) → el riesgo de sesgo se evalúa deprisa (error 9) → las conclusiones se desconectan de la evidencia (error 10).
La consecuencia práctica es que resolver el primer error (registrar protocolo) y elegir herramientas que estructuren el flujo elimina por construcción la mayoría de los errores aguas abajo. No es una solución mágica: requiere disciplina del equipo. Pero la mayoría de los 10 errores frecuentes desaparecen cuando el flujo está bien diseñado desde el inicio.
Cómo SynthIA está construido para prevenir estos errores
SynthIA fue diseñado tomando los 10 errores como punto de partida del diseño del producto. El protocolo se captura como configuración del proyecto y los criterios quedan inmutables salvo declaración explícita de cambio. La búsqueda integra OpenAlex con importación de otras bases. La deduplicación combina coincidencia exacta con detección semántica. El cribado es doble ciego por defecto con cálculo automático del kappa de Cohen. En texto completo, no se puede excluir sin razón categorizada. El diagrama PRISMA 2020 se genera con todas las celdas pobladas a partir del estado operativo del proyecto, no se reconstruye a posteriori. Para una vista panorámica de cómo encaja todo, la introducción a SynthIA y la comparativa frente a otras herramientas en SynthIA vs Rayyan vs Covidence cubren el alcance completo.
