Samsung SDS

Executive Summary

• AI 책임 체계는 담당자 지정만으로 완성되지 않습니다. AI가 어떤 데이터를 사용하고 어떤 권한으로 작동하는지, 문제가 발생했을 때 누가 중단과 재발 방지를 결정하는지까지 연결되어야 합니다.
• AI의 책임 범위는 전체 실행 시스템입니다. 생성형 AI와 AI 에이전트의 결과는 모델뿐 아니라 프롬프트, 검색 데이터, 사용자 권한, API, 업무 규칙의 영향을 함께 받습니다. 따라서 AI 리스크 관리는 모델 성능 점검을 넘어 데이터와 시스템, 권한과 업무 흐름을 함께 확인하는 방식으로 확장되어야 합니다.
• AI 거버넌스는 기획 단계부터 시작해야 합니다. AI를 먼저 배포한 뒤 문제가 생기면 통제를 추가하는 방식은 데이터 분류, 접근 권한, 감사 로그, 사고 대응 절차의 부재로 이어질 수 있습니다. 업무 영향도와 데이터 민감도를 기준으로 필요한 평가·승인·모니터링 절차를 초기 설계에 포함해야 합니다.
• AI는 배포 후에도 지속적으로 평가하고 조정해야 합니다. 모델과 프롬프트, 검색 데이터, 연결된 도구와 외부 서비스는 계속 변경될 수 있습니다. AI가 승인된 역할 범위 안에서 작동하는지, 결과 품질과 업무 성과가 기준을 충족하는지 지속적으로 확인하고 필요하면 권한 축소·사람의 검토·중단을 결정해야 합니다.

이 글은 IDG의 아티클을 전재하여 제공합니다.
[원문보기]

AI 시스템에 담당자가 지정되어 있는데도 문제가 발생하면 책임질 사람이 보이지 않는 경우가 있습니다. 현업은 개발팀을 바라보고, 개발팀은 모델과 데이터 공급자를 바라봅니다. 보안팀과 법무팀은 검토를 담당했을 뿐 운영 책임은 없다고 말합니다. 결국 사고가 발생한 뒤에야 “누가 이 AI를 관리하고 있었는가”를 다시 확인하게 됩니다.

AI 활용이 단순한 질의응답을 넘어 실제 업무 수행으로 확장되면서 이런 문제가 더욱 뚜렷해지고 있습니다. 고객 문의에 답변하고, 내부 데이터를 검색하고, 업무 시스템을 조회하는 수준을 넘어 승인·배포·결제와 같은 행동까지 AI에 맡기는 사례가 늘고 있기 때문입니다.

기존 소프트웨어는 오류가 발생하면 어느 코드와 시스템에서 문제가 시작됐는지 비교적 쉽게 추적할 수 있습니다. 그러나 생성형 AI와 AI 에이전트는 모델, 프롬프트, 검색 데이터, 사용자 권한, API, 업무 규칙이 함께 작동해 결과를 만듭니다. 모델 자체에 문제가 없어도 잘못된 데이터나 과도한 권한, 연결된 시스템의 오류가 AI의 잘못된 판단과 행동으로 이어질 수 있습니다.

이런 환경에서는 “관련 부서가 공동으로 책임진다”는 말만으로는 부족합니다. 전문가들의 제언 역시 AI 책임 체계를 정책과 문서에만 두지 말고, 책임자 지정·데이터 관리·실행 기록·중단 절차·지속적인 감독에 포함해야 한다는 데 초점을 맞추고 있습니다. AI를 실제 업무에 적용하면서도 책임 공백을 만들지 않으려면 무엇을 준비해야 할까요?

AI 책임 체계를 만드는 6가지 방법

1. 프로젝트 시작 단계에서 직접 책임자를 지정한다.

AI 프로젝트에는 여러 조직이 참여합니다. 현업은 업무 목적과 기준을 정하고, 개발팀은 시스템을 구현하며, 데이터팀은 데이터를 관리합니다. 보안·법무·감사 조직은 위험과 규제 요건을 검토합니다.

하지만 여러 조직이 참여한다고 해서 최종 책임자까지 여러 명이어야 하는 것은 아닙니다. 협업을 위한 역할과 사고 대응을 위한 책임자는 구분해야 합니다.

문제가 발생했을 때 인시던트를 선언하고, 배포를 중단할지 판단하고, 사고 원인과 재발 방지책을 관리할 담당자가 필요합니다. 이 사람은 모든 업무를 직접 수행하는 담당자가 아니라, AI 시스템의 사용 범위와 운영 상태를 관리하고 필요한 의사결정을 내리는 오너입니다.

책임자를 지정한다는 것은 다음 질문에 바로 답할 수 있다는 의미입니다.

• 이 AI가 지원하는 업무의 최종 책임자는 누구인가
• 잘못된 출력이나 행동이 발생하면 누가 대응을 지휘하는가
• AI 실행을 중단하거나 사람의 검토로 전환할 권한은 누구에게 있는가
• 모델·데이터·프롬프트가 변경되면 누가 재승인을 결정하는가
• 사고 이후 원인 분석과 재발 방지 조치를 누가 완료하는가

담당자의 이름이 문서에 적혀 있는 것만으로는 충분하지 않습니다. 책임자에게 실제 판단 권한과 조정 권한이 있는지까지 확인해야 합니다.

2. 배포를 확대하기 전에 거버넌스를 설계한다.

AI 시스템을 먼저 개발하고 배포 직전에 보안과 법무 검토를 시작하는 방식은 초기에는 빠르게 보일 수 있습니다. 그러나 실제 운영 단계에서 데이터 분류, 접근 권한, 감사 로그, 변경 관리, 사고 대응 절차가 없다는 사실이 드러나면 배포를 다시 설계해야 합니다.

거버넌스는 프로젝트 마지막에 추가하는 승인 절차가 아니라 기획 단계부터 포함해야 합니다. AI를 어디에 사용하는지, 어떤 데이터를 처리하는지, 어느 수준까지 자동으로 행동하는지, 어떤 상황에서 사람이 검토하는지를 먼저 정해야 합니다.

모든 AI 활용을 같은 수준으로 통제할 필요는 없습니다. 내부 회의록을 요약하는 시스템과 대출 심사를 지원하는 시스템은 업무 영향도와 필요한 통제 수준이 다릅니다. 활용 목적과 위험 수준에 따라 평가·승인·모니터링 절차를 차등화해야 합니다.

좋은 거버넌스는 AI 활용을 무조건 제한하는 체계가 아닙니다. 위험이 낮은 업무는 빠르게 진행하고, 중요한 업무에는 필요한 보호 장치를 적용해 지속적으로 활용할 수 있게 하는 기준입니다.

3. 데이터의 출처와 사용 범위를 관리한다.

AI가 어떤 결과를 만들었는지 확인하려면 먼저 어떤 데이터를 사용했는지 알아야 합니다. 데이터의 출처와 변경 이력, 접근 권한, 사용 목적이 관리되지 않으면 AI의 결과에 문제가 생겨도 원인을 추적하기 어렵습니다.

기업 데이터는 여러 시스템과 부서에 나뉘어 있습니다. 같은 고객이나 상품에 대한 정보가 서로 다른 형식으로 저장되어 있을 수도 있고, 오래된 데이터와 최신 데이터가 함께 사용될 수도 있습니다. AI가 여러 시스템을 조회한다면 어떤 정보가 결과에 영향을 미쳤는지 확인하기도 쉽지 않습니다.

AI에 제공되는 데이터는 최소한 다음 항목을 기준으로 관리해야 합니다.

• 데이터의 소유자와 관리 책임자
• 데이터의 생성·변경 이력
• 개인정보·기밀정보·규제 대상 정보 여부
• AI에 제공되는 데이터의 범위
• 접근 가능한 사용자와 시스템 권한
• 최신성·정확성·완전성 등 품질 기준
• AI 결과에 활용된 데이터의 출처

데이터의 계보와 출처가 관리되지 않으면 사고가 발생했을 때 AI가 어떤 정보를 읽었는지, 그 정보가 적절했는지, 결과에 어떤 영향을 미쳤는지 확인하기 어렵습니다. AI에 입력되는 데이터는 AI의 업무 범위와도 연결됩니다. 데이터 접근 권한과 사용 목적을 관리하지 못하면 모델을 바꾸는 것만으로는 책임 있는 AI 운영을 구현하기 어렵습니다.

4. 모델이 아니라 AI 시스템 전체를 관찰한다.

AI를 모니터링할 때 응답 시간이나 오류율만 확인해서는 충분하지 않습니다. AI가 기술적으로 정상 작동하면서도 업무적으로 잘못된 결과를 만들 수 있기 때문입니다.

AI가 정상적으로 답변을 생성했지만 잘못된 문서를 검색했을 수 있습니다. 올바른 데이터를 사용했더라도 불필요하게 넓은 권한으로 정보를 조회했을 수 있습니다. 에이전트가 API를 정상적으로 호출했지만 호출 대상이나 실행 범위가 적절하지 않았을 수도 있습니다.

문제가 발생했을 때는 다음과 같은 흐름을 다시 구성할 수 있어야 합니다.

• 어떤 요청이 들어왔는가
• 어떤 데이터와 검색 결과를 참조했는가
• 어떤 모델과 프롬프트가 사용됐는가
• 어떤 도구를 어떤 권한으로 호출했는가
• 최종적으로 어떤 행동을 수행했는가

이를 위해 프롬프트, 모델 출력, 검색 결과, 도구 호출, 데이터 접근 기록, 에이전트의 행동 이력을 저장하고 기존 애플리케이션 및 인프라 로그와 연결해야 합니다. 중요한 것은 AI가 무엇을 ‘생각했는지’를 해석하는 것이 아닙니다. 실제 시스템이 어떤 입력을 받고 어떤 처리 과정을 거쳐 어떤 결과와 행동을 만들었는지 확인하는 것입니다.

이러한 관찰 체계는 섀도 AI를 발견하는 데도 필요합니다. 승인되지 않은 외부 AI 서비스로 민감한 데이터가 전송되거나 평소와 다른 API 호출과 데이터 접근이 발생하면, 정책 위반과 보안 위험을 조기에 확인할 수 있어야 합니다.

5. 사람이 개입하고 멈출 수 있는 조건을 정한다.

AI를 업무에 연결할수록 “AI가 무엇을 할 수 있는가”보다 “언제 멈춰야 하는가”가 중요해집니다. 사람이 검토한다는 원칙만 정해서는 부족합니다. 어떤 상황에서 사람에게 넘길지, 누가 검토할지, 검토자가 거부하거나 되돌릴 권한이 있는지, 검토가 끝날 때까지 AI가 추가 행동을 할 수 있는지를 구체적으로 정해야 합니다.

그렇다면 언제 AI의 실행을 멈추고 사람에게 판단을 넘겨야 할까요? 우선 업무별로 정한 최소 평가 기준을 충족하지 못하거나, 답변을 뒷받침할 검색 근거가 없고 서로 충돌하는 경우에는 자동 실행을 중단해야 합니다. 또, 평소와 다른 데이터 접근이나 도구 호출이 감지됐을 때도 마찬가지입니다. 특히 금액·계약·고객 권리·안전에 직접 영향을 미치는 행동이라면 AI가 바로 실행하지 않고 담당자의 확인을 거치도록 해야 합니다. 뿐만 아니라 모델·프롬프트·검색 데이터·권한 정책이 변경된 경우나 일정 기간 동안 결과 품질이 떨어지는 경우에도 재평가가 끝날 때까지 자동 실행 범위를 줄이거나 사람의 검토로 전환할 필요가 있습니다.

중단은 시스템 전체를 종료하는 것만을 뜻하지 않습니다. 특정 도구 호출을 차단하거나, 자동 실행을 승인 대기로 전환하거나, 이전 버전으로 되돌리거나, 사람이 처리하는 절차로 넘기는 것도 중단에 포함됩니다.

AI 장애는 서버가 멈추는 방식으로만 나타나지 않습니다. 답변의 정확도가 서서히 떨어지거나, 정상적인 응답처럼 보이는 오류가 반복될 수도 있습니다. 따라서 AI 인시던트 대응에는 IT 운영뿐 아니라 보안, 법무, 감사, 현업 조직이 함께 참여할 수 있어야 합니다.

무엇보다 사람의 검토 지점은 형식적인 승인 버튼에 그쳐서는 안 됩니다. 실제로 거부할 수 있는 권한과 충분한 검토 시간, AI가 멈춘 뒤 업무를 이어갈 대체 절차가 함께 마련되어야 합니다.

6. 배포 후에도 계속 평가하고 관리한다.

AI 시스템은 한 번 승인하고 배포한 뒤 같은 상태로 유지되는 소프트웨어가 아닙니다. 모델이 업데이트되고, 프롬프트가 변경되며, 검색 데이터와 연결된 도구도 계속 바뀝니다. 외부 AI 서비스를 사용하는 경우에는 공급자가 별도의 변경 승인 없이 모델이나 기능을 바꿀 수도 있습니다.

그 결과 지난 분기에 승인한 AI 서비스가 이번 분기에는 사실상 다른 시스템처럼 작동할 수 있습니다. AI 서비스는 배포하는 순간 관리가 끝나는 것이 아니라, 이후에도 처음 승인받은 업무와 역할 범위 안에서 작동하는지 계속 확인해야 합니다. 운영 과정에서 모델이나 프롬프트, 검색 데이터, 연결된 도구가 변경됐다면 그 변화가 결과의 품질과 업무 수행 방식에 어떤 영향을 미치는지 다시 살펴봐야 합니다.

출력 품질과 업무 성과를 지속적으로 확인하고, 그 과정에서 발생한 사용자 피드백과 오류 사례, 정책 위반이나 예외 처리 기록도 함께 축적해야 합니다. 이러한 기록은 단순히 사고 이후에 확인하는 자료가 아니라 AI의 역할과 권한을 조정하는 근거가 됩니다. 외부 공급자가 모델이나 서비스를 변경한 경우에는 내부 시스템을 직접 수정하지 않았더라도 같은 점검이 필요합니다. 정기적인 재평가를 통해 AI를 현재와 같은 수준으로 계속 맡겨도 되는지, 역할을 축소하거나 사람의 검토를 추가해야 하는지를 판단해야 합니다.

AI 시스템은 배포 시점에 관리가 끝나는 것이 아니라, 운영 과정에서 계속 평가되어야 합니다. 처음 정한 업무 범위와 권한이 현재도 적절한지, 품질이 허용 기준을 충족하는지, 새로운 위험이 생기지는 않았는지 확인해야 합니다. 필요하다면 AI의 역할을 줄이거나 권한을 축소하고, 사람의 검토를 추가하거나, 사용을 중단할 수 있어야 합니다.

사고가 난 후에는 이미 늦습니다

AI 책임 체계는 사고가 발생한 뒤 책임자를 찾아내기 위한 장치가 아닙니다. 사고가 나기 전에 누가 AI를 승인했고, 어떤 데이터와 권한을 부여했으며, AI가 실제로 어떤 과정을 거쳐 결과와 행동을 만들었는지 확인할 수 있도록 하는 구조입니다. 문제가 발생한 뒤 관련 기록을 찾고 여러 부서를 오가는 동안에는 책임의 단서가 이미 서로 다른 시스템과 조직에 흩어져 있을 수 있습니다.

결국 AI를 믿고 맡길 수 있는지는 모델의 성능만으로 판단하기 어렵습니다. 누가 책임지는지, 무엇을 근거로 작동했는지, 실제로 어떤 행동을 수행했는지, 언제 사람에게 판단을 넘기고 멈추는지를 하나의 흐름으로 확인할 수 있어야 합니다. 책임자가 지정되어 있어도 중단할 권한이 없고, 로그가 남아 있어도 데이터와 도구 호출 기록이 연결되지 않는다면 책임 체계는 이름만 남은 상태입니다.

AI 활용이 확대될수록 기업이 설명해야 할 범위도 함께 넓어집니다. 모델의 답변만 설명하는 것으로는 부족합니다. AI가 접근한 데이터와 사용한 권한, 호출한 시스템, 최종적으로 실행한 업무까지 설명할 수 있어야 합니다. 책임의 범위를 모델 바깥의 전체 실행 구조로 확장해야 하는 이유입니다.

AI에 더 많은 일을 맡기기 위해 필요한 것은 막연한 신뢰가 아닙니다. 신뢰가 흔들렸을 때 어디까지 확인할 수 있고, 누가 개입해 바로잡을 수 있는지를 미리 정해두는 일입니다. 문제가 발생했을 때 책임자가 호출되는지, 실행 과정이 남아 있는지, 필요할 때 시스템을 멈출 수 있는지를 함께 봐야 합니다.

준비되지 않은 AI는 업무를 대신하는 것이 아니라 책임의 빈틈을 키울 수 있습니다. 반대로 책임 주체와 실행 기록, 중단 권한이 연결되어 있다면 오류가 발생하더라도 원인을 추적하고 업무를 다시 통제할 수 있습니다. AI가 더 많은 일을 맡는 시대, 기업의 경쟁력은 자율성의 크기만으로 결정되지 않습니다. AI가 멈춰야 할 순간을 설계해 둔 조직과 그렇지 않은 조직 사이에서 격차가 벌어질 것입니다.

FAQ

▶   해당 콘텐츠는 저작권법에 의하여 보호받는 저작물로 기고자에게 저작권이 있습니다.
▶   해당 콘텐츠는 사전 동의 없이 2차 가공 및 영리적인 이용을 금하고 있습니다.