Un gerente dice que la revisión de código ha muerto. Su equipo discrepa. Alguien responde con la pregunta que realmente lo decide: si estás bajo SOC 2, ¿cómo fusionas sin que un humano apruebe el cambio? Un profesional de cumplimiento responde, correctamente, que el marco no le importa cómo ocurre la aprobación, solo que se siga el proceso documentado. Esa respuesta es correcta, y es donde comienza la parte interesante, porque el proceso que un equipo tendría que documentar es más estrecho y extraño de lo que cualquiera de las partes del argumento asume.
Las herramientas disponibles para esto son reales y ya están en funcionamiento: Greptile, GitHub Copilot code review, Claude Code, cada una leyendo pull requests en este momento. Así que la pregunta útil no es si una IA puede aprobar un cambio. Es qué exige SOC 2 de esa aprobación y qué está diseñado para comunicar una señal de revisión de código, frente a lo que una aprobación de cumplimiento aún debe establecer por sí misma.
Qué exige realmente CC8.1
La gestión de cambios de SOC 2 se encuentra en un único criterio, CC8.1. En términos sencillos, exige que un cambio esté autorizado, construido, configurado, documentado, probado, aprobado e implementado mediante un proceso definido, de modo que los cambios lleguen a producción de manera deliberada y no por accidente. Nombra los pasos que un cambio debe superar y espera que tus cambios realmente los superen.
La palabra que sostiene todo el argumento es 'aprobado'. El criterio nombra el paso, pero no quién o qué lo realiza. Los criterios de SOC 2 están redactados para ser basados en principios y neutrales tecnológicamente: tú defines el control que cumple el criterio, y el auditor prueba el control que definiste, tal como está escrito, durante el período. Nada en CC8.1 dice que el aprobador debe ser una persona. Una política que autorice la aprobación automatizada para una clase definida de cambios puede cumplirlo, si el control está delimitado, documentado, opera como lo escribiste y tu auditor lo acepta como tal.
Esto no es hipotético. Los equipos ya están reescribiendo las políticas de gestión de cambios para que los cambios de bajo riesgo puedan ser aprobados por medios automatizados, reservando la aprobación humana para cambios por encima de un umbral de riesgo que ellos definen. Esa es una postura defensible ante CC8.1 cuando puedes demostrarla. Es una política, aplicada y probada, no la ausencia de una.
Las tres cosas que 'la IA lo aprobó' pasa por alto
Primero, la separación de funciones. Una aprobación solo vale algo si el aprobador es independiente del autor. Esa es la expectativa más antigua en la gestión de cambios: la persona que escribió el cambio no es la única que lo aprueba, para que ningún actor único pueda enviar lo que quiera a producción. 'La IA lo aprobó' choca directamente con esto. Si el mismo agente escribe el diff y lo aprueba, o si dos automatizaciones lo hacen sin una verificación independiente entre ellas, has fusionado autor y aprobador. Esa es la parte en la que un auditor insistirá, no la palabra 'IA'.
Segundo, la política debe decirlo explícitamente. Un auditor no prueba tus intenciones, prueba tu proceso documentado frente a lo que ocurrió. 'El bot revisor estaba contento' no es un control a menos que tu política de gestión de cambios defina a ese revisor: qué es, qué cambios puede aprobar, qué verifica y cuándo aún se requiere un humano. Sin eso, una aprobación automatizada no es un control que opera como se diseñó. Es una fusión con un comentario de robot adjunto.
Tercero, el rastro de evidencia es el mismo en cualquier caso. Lo que un auditor muestreará no cambia porque un bot haya aprobado: quiere ver que el cambio fue autorizado, que se probó, quién o qué lo aprobó y que todo esto esté vinculado al cambio y registrado. La aprobación automatizada cumple CC8.1 cuando produce ese rastro en cada cambio que toca. Si no deja el registro, no ha reemplazado el control, lo ha omitido.
Un detalle técnico que el hilo omite: comentar no es aprobar
Detrás de la filosofía hay un detalle de implementación que decide más que la filosofía misma. En el propio modelo de GitHub, un revisor de IA que deja comentarios y un revisor de IA que emite la acción de aprobación son dos cosas diferentes, y las herramientas mencionadas no todas hacen lo segundo.
GitHub Copilot code review, disponible desde 2025, publica sus comentarios como una revisión de tipo Comentario por diseño. Según la propia descripción de GitHub, no cuenta para las aprobaciones requeridas ni bloquea ni desbloquea una fusión. Así que 'que Copilot apruebe' no es, mecánicamente, algo que Copilot haga: un humano requerido o una regla de auto-fusión que hayas configurado sigue emitiendo la acción de aprobación. La acción de pull request de Claude Code lee los cambios y, dependiendo de cómo lo configures, publica sus comentarios como comentarios o como un evento de revisión formal, por lo que qué envía y si eso puede satisfacer una regla de protección de rama es algo que tú configuras y verificas. Greptile lee cada pull request en busca de errores y calidad con contexto de toda la base de código y marca problemas en el cambio.
Así que 'la IA puede aprobar' es una decisión de configuración tanto como de política. Qué herramienta emite qué señal, qué está permitida esa señal para controlar y dónde aterriza el registro son cosas que estableces a propósito, en las reglas del repositorio y la protección de ramas, no cosas que se deriven de un tuit. Establezcanlas deliberadamente, porque esa configuración es el control que su auditor realmente probará.
Una revisión verde no es una revisión de cumplimiento
Incluso cuando la mecánica es correcta, el hilo asume silenciosamente una pregunta más difícil. Todas esas herramientas están diseñadas para responder las preguntas que la revisión de código siempre ha planteado: ¿esto es correcto y es seguro? Esas son las preguntas correctas para hacerle a un diff, y buenas para automatizar. Si el cambio aún cumple con los marcos por los que estás auditado es una pregunta diferente.
Esa segunda pregunta depende de qué controles hayas documentado y en qué se basó tu última auditoría, y no es una propiedad del código que un revisor de errores pueda leer en el diff. Un cambio puede ser correcto, seguro, pasar todas las verificaciones automatizadas y, sin embargo, afectar un control que será muestreado. Aquí está el ejemplo.
export const auditLog = {- retentionDays: 365,+ retentionDays: 30, // trim storage cost}Limpio, correcto y más económico: aquí no hay errores ni vulnerabilidades. SOC 2 no establece un número de retención, pero tu propio control de registro y monitoreo sí, y depende de que estos registros existan durante el tiempo que te comprometiste a conservarlos. Si tu control o evidencia de auditoría asume una ventana más larga, los eventos más antiguos que la nueva no podrán revisarse, y una auditoría que muestre el período encontrará que los registros ya no lo cubren. Establece la retención en función de lo que necesiten tu control y evidencia, no solo de la factura de almacenamiento.
Dónde encaja heygrc
Ese cambio de retención es limpio y correcto en sus propios términos, lo cual es exactamente por qué una pregunta de cumplimiento puede seguir abierta después de que todas las señales de revisión de código estén en verde. Así que cuando una política dice que un cambio fue 'aprobado por medios automatizados', la pregunta honesta de seguimiento es: ¿aprobado como correcto o aprobado como conforme? Esas son dos aprobaciones diferentes, y en ese hilo solo una de ellas estaba sobre la mesa.
heygrc está construido para la segunda. Lee cada pull request frente a los marcos que debes cumplir y nombra el control exacto que un cambio afecta, en el diff, ya sea que lo haya escrito una persona o un agente. No intenta ser un verificador de errores: mantén Greptile, Copilot o Claude Code para la corrección y seguridad, los roles para los que están construidos, y usa heygrc para la lectura de cumplimiento separada, reportada de la única manera en que un hallazgo de cumplimiento vale algo: citando la cláusula.
Si vas a permitir que la aprobación automatizada fusione cambios de bajo riesgo bajo CC8.1, esa es una dirección razonable. Una lectura automatizada de cumplimiento es la verificación faltante que te ayuda a decidir qué cambios son realmente de bajo riesgo en primer lugar. Los ejemplos aquí son ilustrativos, el tipo de cambio que plantea la pregunta en lugar de telemetría que estamos reclamando. Pero el punto se sostiene por sí mismo: SOC 2 nunca requirió que un humano aprobara tus pull requests. Requería que alguien, o algo, los aprobara en el registro, de manera independiente, según un proceso que hayas documentado. Que un revisor de código esté contento no es lo mismo que que ese proceso se haya ejecutado.