안녕하세요. 엔터프라이즈 AI를 위한 AI-Ready Data Platform, Syntitan을 만드는 CUBIG입니다.
AI에 답을 받는 데서 그치지 않고 기업 데이터 조회와 도구 사용, 실제 작업 실행까지 맡기게 되면, 거버넌스가 다뤄야 할 범위도 달라집니다. 정책 문서로 규칙을 정해 두는 것만으로는 부족하고, AI로 작업을 실행하는 과정까지 관리 범위에 넣어야 합니다.
AI 에이전트 거버넌스는 에이전트가 작업할 때마다 누구 이름으로, 어떤 권한과 데이터, 도구로 일했는지, 어떤 평가와 승인을 거쳤는지를 정책과 연결하는 일입니다. 규칙은 정책 문서에 적으면 되지만, 그 규칙대로 실행됐는지 보여 줄 근거는 운영팀이 따로 갖춰야 합니다.
스탠퍼드 AI 인덱스 2026 보고서에 따르면 2025년에 AI 거버넌스를 전담하는 직무가 늘고 책임 있는 AI 정책이 하나도 없다고 답한 기업은 줄었지만, 실행을 가로막는 주요 장벽으로는 지식 부족, 예산 제약, 규제 불확실성이 꼽혔습니다.
에이전트를 도입하는 팀이라면 이런 역량과 예산, 해석의 빈틈을 실행 단계에서 바로 마주하게 됩니다. 이 글에서는 AI 에이전트 거버넌스에 어떤 실행 기록이 필요한지, 그 기록을 AI-Ready Data와 어떻게 이어 운영하는지 살펴봅니다.
AI 에이전트 거버넌스가 실행 단계까지 다뤄야 하는 이유
사내 문서를 요약하는 AI 어시스턴트는 할 수 있는 일이 제한적이지만, 에이전트가 고객 기록을 조회하고, 처리 단계를 직접 바꾸고, 메시지를 보내고, 다른 시스템까지 호출한다면 거버넌스에서 따져야 할 문제의 종류부터 달라집니다.
정책에 “접근은 승인을 받아야 하고, 위험이 큰 작업은 검토를 거쳐야 한다”고 적어 두더라도, 실행 환경에서 이 조건을 강제하고 기록하는 장치는 따로 있어야 합니다. 어떤 에이전트 신원으로 데이터를 요청했는지, 권한은 어떤 사용자나 시스템이 위임했는지 확인할 수 있어야 하고, 어떤 도구를 쓸 수 있었는지, 어떤 외부 콘텐츠가 문맥에 들어왔는지, 실행 전에 어떤 승인이 필요했는지도 남아 있어야 합니다.
미국 국립표준기술연구소(NIST) 산하 국가사이버보안센터(NCCoE)가 2026년에 낸 개념 문서는 소프트웨어와 AI 에이전트의 신원과 권한을 주제로 이 질문들을 구체적으로 다룹니다. 에이전트를 어떻게 식별하고 권한을 줄지, 실행을 어떻게 감사하고 나중에 하지 않았다고 부인하지 못하게 할지, 악의적인 문장으로 지시를 바꾸는 공격(프롬프트 인젝션)을 어떻게 막을지를 두고 의견을 받았습니다. NIST의 AI 에이전트 표준 이니셔티브도 에이전트를 믿고 도입할 수 있도록 신원, 인증, 상호운용성, 보안 평가에 집중하고 있습니다.
운영하는 입장에서는 이런 통제가 기록으로 남아야 하고, 기록이 없으면 원래 어떻게 처리됐어야 하는지는 알아도 실제로 어떻게 처리됐는지는 확인하기 어렵습니다.
정책 문서만으로는 문제가 된 실행을 되짚을 수 없습니다
보험금 심사를 돕는 에이전트가 제출된 서류를 읽고 약관 데이터를 조회해 처리 방향을 추천하고, 일부 건은 담당자에게 넘겨 승인을 받는다고 가정해 보겠습니다.
회사에 개인정보, 접근 권한, 모델 검토, 사람의 감독에 관한 규정이 이미 있더라도, 추후 결정에 이의가 제기되면 규정 문서만으로는 아래 질문에 답하기 어렵습니다.
- 에이전트가 조회한 약관 데이터는 어느 버전이었는가?
- 평가 데이터에 해당 청구인과 같은 유형의 사례가 들어 있었는가?
- 어떤 프롬프트와 모델, 도구 설정으로 추천을 만들었는가?
- 출처를 믿을 수 없는 서류 속에 숨은 문장을 에이전트가 지시로 받아들이지는 않았는가?
- 어느 담당자가 그 작업을 승인했고, 승인할 때 어떤 근거를 봤는가?
- 마지막으로 시험을 통과한 때부터 문제가 된 실행까지 무엇이 바뀌었는가?
정책은 의도를 정할 뿐이고, 그 의도대로 돌아갔는지는 실행할 때마다 남긴 근거를 봐야 알 수 있습니다.
솔루션 기업들도 정책을 문서에서 꺼내 실행 단계에 거는 제품을 내놓고 있습니다. 2026년 9월 한 데이터 거버넌스 솔루션 기업은 AI 에이전트가 해야 할 일과 해도 되는 일을 기계가 읽을 수 있는 규칙으로 정하는 에이전트 계약 기능을 소개했는데, 실행 중에는 감독 역할을 맡은 에이전트가 이 규칙을 기준으로 에이전트의 동작을 지켜보는 방식입니다. 이런 규칙으로 에이전트에게 무엇이 허용됐는지는 알 수 있지만, 위 질문에 답하려면 에이전트가 어느 버전의 데이터를 조회했는지, 마지막으로 시험을 통과한 뒤 무엇이 바뀌었는지처럼 실제로 무엇이 실행됐는지 보여 주는 기록이 있어야 합니다. 이 기록은 분쟁이 생긴 뒤에 그러모으는 자료가 아니라 실행할 때마다 업무 흐름과 함께 쌓이는 운영 기록이어야 합니다.
OWASP의 프롬프트 인젝션 대응 지침을 보면 정책이 실행 단계의 통제로 바뀐 모습을 실무 수준에서 볼 수 있습니다. 이 지침은 접근 권한을 최소한으로 주고, 위험이 큰 작업은 사람이 승인하고, 믿을 수 없는 콘텐츠는 따로 떼어 두고, 공격을 가정해 시험하라고 권하는데, 네 가지 모두 에이전트가 작업을 실행하는 방식 자체를 바꾸는 통제입니다. 실행 한 건을 되짚을 때는 이 통제들이 그때 작동했는지 확인할 근거도 남아 있어야 합니다.
문제가 된 실행을 되짚으려면 누가 어떤 권한으로 실행했는지와 그때의 데이터 상태, 설정, 검토, 변경 이력을 그 실행에 묶어 두어야 합니다.
규제가 운영 근거의 가치를 키우고 있습니다
EU AI Act는 2026년 8월 새로운 집행 단계에 들어갔습니다. 유럽연합 집행위원회가 공개한 일정에 따르면 AI 사무국과 각국 당국은 2026년 8월 2일부터 이 단계에 해당하는 조항을 집행할 권한을 갖습니다. 고위험 AI의 유형별 의무는 2027년과 2028년에 걸쳐 단계적으로 적용됩니다.
국내에서도 AI 기본법이 2026년 1월 22일부터 시행됐습니다. 고영향 AI를 제공하는 사업자는 위험관리, 결과 설명, 이용자 보호, 사람의 관리와 감독 조치를 이행하고, 그 조치 내용을 확인할 수 있는 문서를 작성해 보관해야 합니다(제34조). 조치하겠다고 적어 두는 것만으로는 부족하고, 실제로 조치했다는 기록까지 남겨야 한다는 뜻입니다. 국내 기준은 AI 기본법 대비, AI 사용 규정만 만들면 끝일까?에서 자세히 정리했습니다.
시행 날짜도 중요하지만, 길게 보면 AI를 운영하는 방식 자체가 바뀐다는 점을 더 눈여겨봐야 합니다. EU AI Act는 투명성, 감독, 위험관리, 데이터 품질, 로그, 문서화를 요구하는데, 이 요건은 정책 파일 하나로는 충족하기 어렵고 검토하는 시스템과 업무, 데이터, 결정마다 연결된 근거가 있어야 합니다.
이 글은 법률 자문이 아니며 구체적인 의무는 역할과 업무에 따라 달라지지만, 운영팀이 참고할 방향은 분명합니다. 사고가 터진 뒤에 누군가 티켓과 스프레드시트, 모델 대시보드, 접근 로그를 뒤져 짜 맞추기 전에, AI로 처리한 작업의 근거를 바로 꺼내 볼 수 있어야 합니다.
AI 에이전트 거버넌스에 필요한 근거 묶음
기록을 한 제품에 모아 둘 필요는 없지만, 실행이나 결정 한 건을 기준으로 서로 찾아갈 수 있게 이어져 있어야 합니다.
| 운영 질문 | 남겨 둘 근거 | 근거가 없을 때 생기는 문제 |
|---|---|---|
| 누가 또는 무엇이 실행했는가? | 에이전트 신원, 권한을 위임한 주체, 세션, 인증 | 승인받은 주체가 실행한 작업인지 확인할 수 없습니다 |
| 무엇을 할 수 있도록 허용됐는가? | 역할, 정책 판단, 도구 범위, 데이터 권한, 승인 요건 | 에이전트가 허용 범위를 넘거나 지나치게 넓은 권한을 물려받아도 확인할 수 없습니다 |
| 어떤 상태의 데이터가 실행에 들어갔는가? | 데이터셋 버전, 출처, 변환 내역, 라벨, 기간 | 오래됐거나 업무와 맞지 않거나 출처를 설명할 수 없는 데이터로 결과를 내도 알 수 없습니다 |
| 원래 하려던 업무는 무엇이었는가? | 업무 정의, 대상 집단, 허용 조건, 판단 기준값 | 이 용도로 시험한 적이 없는 시스템을 그대로 쓰게 됩니다 |
| 평가할 때 무엇이 일어났는가? | 비교에 쓴 입력, 설정, 출력, 지표, 예외, 검토 | 통과했다는 결과를 다시 확인할 길이 없고, 어디까지 믿을지도 정하기 어렵습니다 |
| 그 뒤에 무엇이 바뀌었는가? | 버전 비교, 드리프트(결과가 서서히 달라지는 현상) 신호, 사고, 정책 변경, 재점검 계기 | 예전에 받은 승인이 계속 유효한 것처럼 다루게 됩니다 |
이렇게 근거를 묶어 두면 결정이 어떤 경로로 내려졌는지 살펴볼 수 있고, 성격이 다른 통제를 종합 점수 하나로 뭉뚱그리는 일도 막을 수 있습니다. 접근 통제는 제대로 작동해도 데이터가 그 업무에 맞지 않을 수 있고, 모델이 평가를 통과했어도 도구 권한이 너무 넓게 열려 있거나 검토자가 판단에 필요한 근거를 보지 못한 채 승인하는 경우가 있습니다.
거버넌스를 운영으로 옮기는 다섯 가지 방법
1. 통제를 고르기 전에 작업부터 정의합니다
AI 시스템이 무엇을 읽고, 만들고, 바꾸고, 실행할 수 있는지부터 정합니다. 챗봇과 코파일럿, 자율 에이전트는 할 수 있는 일의 범위가 서로 다르기 때문에, 통제는 모델 이름이 아니라 실제 업무 흐름에 맞춰 정해야 합니다.
2. 권한을 특정 신원과 세션에 묶습니다
에이전트 신원, 권한을 위임한 사용자나 시스템, 쓸 수 있는 도구, 권한이 유지되는 기간을 기록합니다. 한 업무에 필요한 권한이 좁다면 에이전트에도 그만큼만 주고, 넓은 접근 권한을 늘 열어 두지 않습니다.
3. 데이터 버전과 상태를 업무에 연결합니다
데이터에 접근할 수 있다는 것은 데이터를 꺼내 볼 수 있다는 뜻일 뿐, 그 데이터가 업무에 맞는다는 뜻은 아닙니다. 데이터 버전과 출처, 쓰려는 용도, 대상 집단, 알려진 한계를 기록하고, 이 데이터가 정해 둔 업무에 맞는지 견주어 봅니다. 접근할 수 있는 데이터와 AI에 쓸 수 있는 데이터의 차이를 정리한 글(영문)에서 다룬 구분과 같습니다. 접근 권한이 있으면 검토를 시작할 수 있고, 결정은 업무에 맞춘 근거가 있어야 내릴 수 있습니다.
4. 시스템 전체를 시험합니다
모델, 프롬프트, 검색해 온 데이터, 도구, 권한, 승인 경로를 한꺼번에 평가합니다. 실제 업무에는 외부 콘텐츠와 사내 시스템이 얽혀 있어서, 모델만 따로 측정한 벤치마크 점수로는 업무에서 어떻게 돌아갈지 알 수 없습니다.
5. 다시 결정해야 하는 계기를 정해 둡니다
배포하기 전에 재점검 계기를 정합니다. 모델을 업데이트하거나 데이터를 바꾸거나 새 도구를 추가할 때는 물론, 권한 변경이나 드리프트 신호, 사고, 정책 변경이 생겨도 예전 근거가 더는 맞지 않을 수 있습니다. 거버넌스 차원에서는 첫 배포를 누가 승인했는지 남기는 데 그치지 않고, 언제 다시 시험할지도 정해 둬야 합니다.
이 다섯 가지를 운영에 옮기면, 아래처럼 범위 정의에서 재점검까지 되풀이되는 흐름이 됩니다.
| 변경 신호 | 다시 열어 볼 근거 | 최소한 내려야 할 결정 |
|---|---|---|
| 모델이나 프롬프트 변경 | 평가 설정, 동작 시험, 예외 검토 | 예전 비교 결과가 그대로 유효한지 확인하거나 비교를 다시 합니다 |
| 데이터셋 변경 | 출처, 스키마, 대상 집단, 라벨 이력, 업무 정의 | 새 데이터 상태가 업무에 맞는지 다시 확인합니다 |
| 새 도구 추가나 권한 확대 | 에이전트 권한, 도구 범위, 승인 경로, 악용 시험 | 넓어진 작업 범위를 받아들일 수 있는지 판단합니다 |
| 드리프트 신호나 사고 | 실행 로그, 영향받은 대상, 출력, 검토, 이전 기준값 | 업무 흐름의 영향 범위를 묶어 두고, 고칠지 다시 시험할지 중단할지 정합니다 |
| 정책이나 규제 변경 | 요구 사항, 통제, 보관 기간, 담당자 | 다음 실행 전에 운영 조건을 고칩니다 |
CUBIG의 관점: 거버넌스에는 운영 모델이 필요합니다
CUBIG은 AI-Ready Data를 인증이나 점수 하나로 보지 않고, 특정 AI 업무에 맞게 준비하고 확인한 데이터로 봅니다. Syntitan에서 Ready for Raw Data는 데이터 상태를 여섯 가지 기준으로 진단하고, 그 결과를 나중에 다시 꺼내 볼 수 있는 Version으로 남깁니다. Ready for Model은 정해진 모델 업무에서 같은 평가 조건으로 준비 전후 결과를 비교해, 합의한 기준을 충족하는지 확인합니다. Ready for Agent는 에이전트가 할 일(Task)과 그 일이 벌어지는 구체적 상황(Case)을 만들어, 실제 업무 상황에 맞춰 데이터를 확인합니다. 세 가지 Ready는 차례로 거쳐야 하는 단계가 아니어서, 업무에 필요한 것부터 골라 쓸 수 있습니다. 실제 에이전트 실행과 연결하고, 재검증하고, 변경을 추적하는 기능은 12월에 제공할 예정입니다.
이 방식은 AI를 운영하는 틀일 뿐 어떤 규정에나 그대로 들어맞는 준수 체계는 아니어서, 지켜야 할 요건은 법무, 보안, 위험관리 쪽에서 정합니다. 운영 모델은 그 요건을 AI로 내린 결정에 쓰인 데이터 상태와 업무, 시험, 변경 이력에 연결합니다.
요건을 정하는 일과 근거를 연결하는 일을 나눠 보는 이유는, 거버넌스 위원회가 정책을 승인했더라도 운영팀에는 따로 근거가 있어야 하기 때문입니다. 특정 AI 업무 흐름을 확대할지, 고칠지, 다시 시험할지, 멈출지는 그 근거로 판단합니다.
업무 흐름 하나부터 시작합니다
모든 AI 기록을 한 번에 모으려 하면, 팀에 무엇이 필요한지 확인하기도 전에 긴 시스템 구축 사업이 되기 쉽습니다. 시작할 업무 흐름은 민감하거나 결과에 큰 영향을 주는 데이터를 AI로 처리하는 업무, AI에 도구 사용을 맡기는 업무, AI 결과가 결정에 영향을 주는 업무 가운데 하나만 고릅니다.
그 업무 흐름의 작업 범위를 정하고, 누가 어떤 권한을 위임받아 실행하는지 확인합니다. 쓸 데이터의 버전을 그 업무에 연결하고, 데이터를 업무에 맞게 준비하기 전과 후를 같은 조건에서 비교하고, 그 조건을 기록해 둡니다. 그다음 어떤 변화가 생기면 이 근거가 무효가 되는지 정합니다.
이 순서를 따르면 거버넌스팀은 정책 문서를 하나 더 만드는 것보다 쓸모 있는 결과를 얻습니다. 운영팀도 권한을 넓힐지, 업무 흐름을 제한할지, 데이터를 고칠지, 시스템을 다시 시험할지, 배포를 멈출지 정할 때 근거를 들어 이유를 설명할 수 있습니다.
AI 업무 하나를 골라 그 업무의 기준으로 먼저 시험한 뒤에 접근 권한과 실행 권한을 넓혀 보세요. Syntitan이 AI-Ready Data 판단을 어떻게 돕는지 확인해 보세요.
