AI 거버넌스의 빈틈은 기술 구조에서 생긴다

보안 정책에 금지 사항을 적는다고 기술이 저절로 따르지는 않는다. AI에서는 조직들이 이 교훈을 더 빠르고 훨씬 큰 비용을 들여 다시 배우고 있다는 주장이다.

이 글은 AI 거버넌스의 핵심 문제를 정책이 아니라 아키텍처에서 찾는다. 조직이 AI 시스템의 정보 흐름과 통제 경계를 파악하지 못하면 정책을 집행하거나 문제가 생긴 뒤 확인하기 어렵다는 논지다. AI 도입을 검토하거나 관리하는 조직이라면, 승인 절차를 늘리기 전에 시스템이 실제로 무엇을 보고 무엇을 할 수 있는지 살펴보라는 제안이다.

정책만으로 통제가 되는가?

조직은 어떤 모델과 제품을 허용할지, 직원이 어떤 정보를 입력할 수 있는지, 어떤 사용 사례를 더 면밀히 살필지 정할 수 있다. 그러나 기밀 정보를 외부 모델에 입력하지 말라는 정책은 기대하는 행동을 정할 뿐이다. 그 기대를 강제할 수 있는지, 위반을 탐지할 수 있는지, 사후에 무슨 일이 있었는지 파악할 수 있는지는 아키텍처가 좌우한다.

아키텍처는 프롬프트가 기업 내부 경계를 벗어나는지, 어디서 처리되고 보관되는지, AI 서비스가 어떤 시스템에 접근하는지, 어떤 정보를 검색할 수 있는지, 결과물이 어디에 저장되는지를 결정한다. 문제가 생겼을 때 상호작용을 재구성할 수 있는지도 여기에 달려 있다.

조직들은 보안 정책에 적어 놓는 것만으로 기반 기술이 그 규칙을 따르게 되지 않는다는 사실을 수십 년간 확인해 왔다. 이 글은 AI가 같은 교훈을 더 빠르게, 훨씬 큰 예산을 들여 다시 배우게 했다고 지적한다. 거버넌스가 아키텍처의 통제 없이 정책을 따르는 사람에게 크게 의존하면, 민감 정보가 경계를 넘지 않도록 직원이 정책의 특정 문단을 기억하길 바라는 데 그칠 수 있다. 이는 실질적인 통제라기보다 요청에 가깝다.

AI 시스템의 경계는 어떻게 달라졌나?

기존 기업 시스템은 대체로 애플리케이션, 인프라, 인터페이스, 데이터 저장소로 경계를 파악할 수 있었다. AI가 들어간 업무 과정은 직원용 애플리케이션, 기업용 AI 플랫폼, 검색·검색 결과 제공 계층, 내부 데이터 원천, 외부 기반 모델, 다른 시스템에서 작업을 수행하는 도구까지 이어질 수 있다. 이 가운데 일부는 기업이 운영하고, 일부는 기술 제공업체가 운영하며, 또 일부는 그 업체의 협력업체가 운영할 수 있다.

에이전트는 프롬프트에 답해 문장을 돌려주는 데서 그치지 않을 수 있다. 필요한 정보를 고르고, 도구를 호출하고, 다른 시스템과 상호작용할 수 있다. 따라서 조직이 AI에 기업 시스템 접근 권한을 부여할수록 어떤 모델을 쓰는지보다 전체 시스템이 무엇을 할 수 있는지 아는 일이 중요해진다. 모델이 무엇을 볼 수 있고, 무엇을 할 수 있으며, 어떤 경계를 넘어 정보가 어디로 가는지 확인해야 한다.

주권은 위치보다 통제의 문제인가?

이 글은 AI 주권을 내부 호스팅은 안전하고 외부 모델은 위험하다는 식으로 단순화하지 말라고 주장한다. 민감한 정보에 제한 없이 접근하고 신원 확인과 기록 관리가 허술한 내부 모델은 큰 위험을 낳을 수 있다. 반대로 강한 계약상·기술적·데이터 통제를 갖춘 외부 모델은 상대적으로 위험이 작을 수 있다. 규제와 관할권을 고려하면 위치도 중요하지만, 그것만으로 통제를 판단할 수는 없다.

더 중요한 질문은 통제권이 어디에 있는지다. 인프라와 데이터를 누가 통제하는지, 신원과 접근 권한을 누가 정하는지, 정보가 어디에서 처리되고 보관되는지, 어떤 관할권이 적용되는지, 서비스에 다른 조직이 참여하는지 살펴야 한다. 기업이 실제 처리 내역을 확인할 수 있는지, 모델 주변의 모든 것을 다시 만들지 않고도 제공업체를 바꿀 수 있는지도 따져야 한다.

이 관점에서 주권은 단순한 호스팅 선택이 아니다. 조직이 기술과 정보, 미래의 선택에 대해 실질적인 통제력을 얼마나 유지하는지를 뜻한다. 이 통제력을 조달 계약이 끝난 뒤 점검표에 덧붙일 것이 아니라 아키텍처에 반영해야 한다.

거버넌스가 무엇을 입증해야 하나?

AI 시스템이 결정을 내리거나 작업을 수행한 과정을 재구성할 수 없다면, 거버넌스는 증거보다 신뢰에 의존하게 된다. AI가 사람을 돕는 데서 업무 과정에 직접 참여하는 단계로 나아갈수록, 위험 수준에 맞는 기록이 필요하다. 모든 상호작용의 토큰을 영원히 보존해야 한다는 뜻은 아니다. 중요한 업무에서는 어떤 모델이 쓰였는지, 모델에 어떤 정보가 주어졌는지, 어떤 자료를 검색했는지, 어떤 도구에 접근할 수 있었는지, 어떤 작업을 시도했는지, 어떤 통제가 적용됐는지 확인할 근거가 필요할 수 있다.

대부분의 기록은 조사 대상이 되지 않을 수 있다. 감사 가능성을 갖추는 목적은 모든 거래를 조사하는 데 있지 않다. 중대한 일이 생겼을 때 통제가 작동했다는 점을 입증할 수 있어야 그 통제에 의존할 수 있기 때문이다. 이를 보여줄 증거가 없으면 AI 거버넌스 위원회는 구성원들이 여전히 정책에 동의하는지 확인하는 자리에 머물 수 있다.

조직은 새 승인 절차를 만들기 전에 AI 환경을 충분히 정확하게 지도화해야 한다. 어떤 모델과 플랫폼을 쓰는지, 어떤 정보에 접근할 수 있는지, 어떤 신뢰 경계를 넘는지, 외부 조직이 어디에 참여하는지, 어떤 작업을 할 수 있는지, 각 경계에 어떤 통제가 있는지 살펴야 한다. 이 과정에서 중복 플랫폼, 통제되지 않은 실험, 겹치는 공급업체 관계, AI 시스템이라고 여기지 않았던 제품에 들어간 AI 기능이 드러날 수 있다. 문서로 정한 거버넌스 요구사항을 현재 아키텍처로는 집행할 수 없다는 사실도 확인될 수 있다.

글의 주장은 거버넌스가 AI 사용을 막는 데 목적을 두어서는 안 된다는 것이다. 경계를 이해하면 안전하게 실험할 곳과 추가 통제가 필요한 곳, 더 엄격하게 살필 만한 결과가 따르는 곳을 구분할 수 있다. 반대로 무슨 일이 일어나는지 설명할 수 없으면 모든 사용을 제한하는 편이 합리적으로 보일 수 있다. 이는 일부 위험을 막지만 혁신도 가로막는다. 위험, 보안, 법무, 기술 조직은 각각 문제의 일부만 보므로, 실제 통제 범위를 정하는 아키텍처를 함께 살펴야 한다.

원문은 구체적인 조직 사례나 아키텍처를 구현하는 절차는 제시하지 않는다. 다만 AI 환경을 지도화할 때 확인할 항목과 각 경계의 통제를 파악해야 한다고 제안한다.