Oracle Deep Trust AI Architecture, AI 보호 기능을 엔터프라이즈 스택으로 확장

Oracle은 10월 26일 Oracle Deep Trust AI Architecture를 발표하며, 개별 AI 애플리케이션에만 집행을 맡기는 대신 엔터프라이즈 기술의 네 계층에 걸쳐 보호 기능을 배치했다. 이 청사진은 소프트웨어 플랫폼, 데이터, 데이터 접근, 애플리케이션 개발을 포괄한다. 핵심 주장은 실용적이다. AI 모델이 실수하더라도 효과를 유지하는 통제가 기업에 필요하다는 것이다.

이번 발표는 모델을 사용해 도구를 선택하고 작업을 수행하는 소프트웨어인 AI 에이전트를 겨냥한다. 이러한 시스템은 까다로운 아키텍처 질문을 제기한다. 에이전트가 새로운 경로를 통해 비즈니스 데이터에 접근한다면, 기존 애플리케이션에 내장된 제한은 여전히 적용될까?

Oracle의 답변은 애플리케이션 하위 계층에서의 집행을 강조한다. AWS는 에이전트 실행 경계 외부의 AgentCore 통제를 통해 유사한 목표를 추구한다. 의미 있는 비교는 각 접근 방식이 정책을 어디서 집행하는지, 무엇을 포괄하는지, 고객이 여전히 무엇을 구성해야 하는지에 관한 것이다. 엔터프라이즈 구매자에게 이는 소프트웨어만큼이나 책임에 관한 결정이 된다.

Oracle Deep Trust AI Architecture, 네 가지 통제 계층 연결

Oracle은 신뢰할 수 있는 동작을 보장하는 모델을 발표하는 것이 아니라, 기존 제품 기능을 결합한 아키텍처 청사진을 제시하고 있다.

10월 26일 엔터프라이즈 AI 아키텍처 발표는 라스베이거스에서 열린 Oracle AI World에서 이뤄졌다. 이는 Oracle AI Database, Oracle Autonomous AI Database, Oracle APEX AI Application Generator를 결합한다.

Oracle은 이 접근 방식을 신뢰성 높은 시스템 설계를 위한 자사의 청사진인 Maximum Availability Architecture와 비교한다. 여기서 조직화 목표는 AI 접근과 행동에 대한 통제를 유지하는 것이다. 회사는 공유 보호 기능이 모든 애플리케이션에서 개별적으로 구현되는 보호 장치에 대한 의존을 줄일 수 있다고 말한다.

무엇이 바뀌었는지 평가할 때 이 구분은 중요하다. 아키텍처 발표는 모든 구성 요소가 발표일에 새로 제공된다는 의미 없이 공통 설계 방향을 수립할 수 있다. 구매자는 청사진의 공개와 실제 배포하려는 각 기능의 출시 상태를 구분해야 한다.

실질적 의미는 이러한 구성 요소들이 함께 작동하도록 설계된 방식에 있다. 기업은 이미 데이터베이스 권한, 애플리케이션 검사, 운영 보안 프로세스를 갖추고 있을 수 있다. 아키텍처상의 질문은 에이전트가 시스템을 통과하는 또 다른 경로를 도입할 때 이들이 일관된 경계를 형성하는지 여부다.

구매 기록을 읽고 변경안을 작성하는 가상의 조달 보조 도구를 생각해 보자. 일반 애플리케이션 인터페이스는 직원의 권한을 벗어난 요청을 거부할 수 있다. 보조 도구가 그 인터페이스를 전혀 열지 않더라도, 기초 데이터에 대한 별도 연결에는 동등한 제한이 필요하다.

이 사례는 고객 배포 사례를 기록하는 것이 아니라 Oracle이 해결하려는 문제를 보여준다. 통제는 워크플로가 실제로 이를 거칠 때에만 워크플로를 보호한다. 다른 경로가 해당 검사를 완전히 우회한다면 애플리케이션 검사를 하나 더 추가해도 안심할 근거는 제한적이다.

따라서 Oracle의 제안은 평가 대상을 바꾼다. 구매자는 사람의 요청과 중요한 시스템 조치 사이의 전체 경로를 검토해야 한다. 보조 도구의 눈에 보이는 대화만 검토하면 그 경로의 중요한 부분은 살펴보지 못하게 된다.

네 계층 프레임은 신뢰의 서로 다른 의미도 구분한다. 플랫폼을 유지 관리하는 일은 레코드 접근을 제한하는 일과 다르다. 접근 제한은 재무 관련 질문을 정확히 해석하는 일과도 다르다. 애플리케이션은 한 책임에서는 성공하면서 다른 책임에서는 실패할 수 있다.

발표를 지켜보는 독자에게 이 구분은 필수적이다. “신뢰할 수 있는 AI”는 하나의 제품 속성처럼 들릴 수 있다. 이 청사진에서 이는 서로 다른 증거, 책임자, 수용 기준이 필요한 여러 엔지니어링 책임을 의미한다.

뉴스의 핵심은 조율된 아키텍처와 집행에 대한 강조다. 이 청사진을 도입하는 모든 기업이 이미 이러한 책임을 해결했다는 점을 입증하는 것은 아니다.

데이터 소유자가 가장 까다로운 거버넌스 결정을 마주한다

스택의 더 깊은 계층으로 집행을 옮기면 규칙을 정확하게 정의하는 일이 더욱 중요해진다.

Oracle의 데이터 보안 설계는 최종 사용자의 검증된 신원에 연결된 데이터베이스 집행을 설명한다. 관계형 데이터를 조회하고 수정하는 데 사용되는 언어인 SQL은 이러한 규칙의 적용을 계속 받는다.

회사는 정의된 비즈니스 요구사항을 위반하는 변경을 거부하는 데이터베이스 조건인 SQL Assertions도 설명한다. 예시는 직원 지출 한도에 관한 것이다. 이러한 메커니즘은 에이전트가 지침을 기억하는 데 의존하지 않고 접근과 유효한 변경을 다룬다.

엔터프라이즈 팀에 주는 시사점은 조직적이다. 누군가는 어떤 권한과 비즈니스 조건을 해당 집행 지점에 둘지 결정해야 한다. 기술 시스템은 규칙을 일관되게 적용할 수 있지만, 조직은 그 규칙이 무엇을 허용해야 하는지를 두고 여전히 의견이 갈릴 수 있다.

가상의 구매 워크플로는 이 차이를 분명하게 보여준다. 구매 요청을 볼 권한이 반드시 이를 승인할 권한을 뜻하지는 않는다. 요청 승인 권한은 부서, 요청 목적 또는 일시적 위임에 따라 달라질 수 있다.

이는 개발자뿐 아니라 프로세스 소유자에게도 해당하는 질문이다. 데이터베이스 관리자는 합의된 조건을 구현하는 데 도움을 줄 수 있다. 그러나 그 관리자가 비공식 대화에서 모호한 구매 정책을 추론해야 해서는 안 된다.

따라서 Oracle AI 거버넌스는 엔터프라이즈 정책 정의의 품질에 부담을 준다. 관행으로만 표현된 규칙은 소프트웨어에 명시적인 결정이 필요해질 때 관리하기가 더 어려워진다. 예외는 일반 워크플로에 숨겨진 가정을 드러내는 경우가 많으므로 특히 주의가 필요하다.

그렇다고 모든 판단을 데이터베이스 내부에 넣어야 한다는 뜻은 아니다. 일부 결정은 그 범위 밖의 정보에 의존한다. 다른 결정은 사람의 재량이나 다른 시스템의 승인을 요구한다. 아키텍처는 각 통제가 무엇을 판단할 수 있는지에 관한 명확한 경계를 필요로 한다.

조달 사례는 자격과 의도 사이의 차이도 드러낸다. 요청은 지출 한도를 충족하면서도 잘못된 품목을 구매할 수 있다. 한도 집행은 정의된 조건을 다루지만, 해당 구매가 비즈니스에 기여한다는 점을 입증하지는 않는다.

이 차이는 구매 결정에 반영돼야 한다. 팀은 제안된 통제가 어떤 실패를 방지하고 어떤 실패가 여전히 가능한지 식별해야 한다. 거버넌스에 대한 포괄적 약속보다 포괄하는 조치를 명시적으로 설명하는 편이 더 유용하다.

개발자는 이와 관련된 책임 변화를 마주한다. 공유 집행은 반복 작업을 줄일 수 있지만, 애플리케이션은 여전히 거부를 올바르게 처리해야 한다. 보조 도구는 거부된 조치를 정확히 설명해야 하며, 그 거부를 우회해야 할 기술적 문제로 취급해서는 안 된다.

데이터 소유자는 정책 변경을 위한 프로세스도 필요로 한다. 배포 당시에는 올바른 규칙이었더라도 조직 개편이나 승인 프로세스 개정 이후에는 낡을 수 있다. 신뢰할 수 있는 집행은 규율 있는 업데이트의 가치를 높인다. 그 결과가 적용 대상인 모든 애플리케이션에 미치기 때문이다.

따라서 성공의 관련 척도는 정책 엔진이 실행되는지 여부보다 넓다. 조직은 정책의 의미, 소유권, 예외, 검토에 대해 합의해야 한다. 이러한 결정이 일관된 집행이 실제로 무엇을 달성하는지 결정한다.

공유 집행이 Oracle과 AWS의 비교를 바꾼다

애플리케이션 하위 계층의 통제에 대한 Oracle의 강조는 엔터프라이즈 AI 권한이 어디에 있어야 하는지를 둘러싼 더 광범위한 경쟁에 속한다.

AWS는 AgentCore 정책 집행을 도구 접근을 중개하는 서비스인 Gateway에서 설명한다. AWS에 따르면 Policy는 에이전트 코드 외부에서 도구 호출을 평가하고 허용된 조치를 규정하는 규칙을 적용한다.

이는 동등한 적용 범위를 입증하지 않으면서도 중요한 비교를 제공한다. Oracle은 데이터베이스와 애플리케이션 스택을 강조한다. AWS는 도구 접근 주변의 집행을 설명한다. 두 접근 모두 에이전트 내부에 포함된 지침에만 의존하는 방식에 이의를 제기하지만, 집행 지점은 서로 다른 아키텍처 역할을 수행한다.

게이트웨이는 제안된 도구 호출이 허용되는지 평가할 수 있다. 데이터베이스 통제는 요청이 데이터베이스에 도달했을 때 접근 또는 변경을 평가할 수 있다. 기업에 어느 접근법이 필요한지, 또는 둘 다 필요한지는 워크플로와 기존 시스템에 따라 달라진다.

그러므로 구매자에게 유용한 질문은 구체적이다. 요청이 효과를 내기 전에 반드시 통과해야 하는 지점은 어디인가? 팀이 그 주변 또는 그 이후의 모든 경로를 식별할 수 있을 때 집행 지점을 보여주는 다이어그램은 의미를 갖는다.

예를 들어, 승인된 도구를 통해 비즈니스 레코드를 업데이트할 수 있는 보조 도구를 상상해 보자. 같은 환경에는 더 넓은 권한을 가진 또 다른 통합이 있을 수도 있다. 평가는 승인된 도구가 전체 경계를 나타낸다고 가정하지 말고 두 경로를 모두 살펴봐야 한다.

이는 어느 한 공급업체 제품의 확인된 취약점을 주장하는 것이 아니라 분석을 위한 사례다. 기능 이름을 비교하는 것만으로는 지침이 제한적인 이유를 보여준다. 적용 범위는 실제 배포와 구성 요소에 부여된 권한에 따라 결정된다.

따라서 Oracle 에이전트 보안은 고객의 데이터 경로를 기준으로 평가해야 한다. 관련 레코드와 규칙이 데이터베이스에 존재한다면 데이터베이스 중심 설계는 면밀한 검토가 필요하다. 외부 서비스를 아우르는 워크플로에는 해당 서비스에 적합한 통제도 필요하다.

비교 시 Oracle의 접근 방식을 경쟁사가 프롬프트에만 의존한다는 증거로 취급해서는 안 된다. AWS 문서는 외부 집행을 명시적으로 설명한다. 경쟁상의 차이는 통합, 적용 범위, 관리, 그리고 일관된 정책을 유지하는 데 필요한 작업에 관한 것이다.

책임을 통합하는 데에는 상충 관계도 있다. 공유 통제는 팀에 정책을 검토할 공통 지점을 제공해 감독을 단순화할 수 있다. 반면 공유 구성의 오류는 여러 애플리케이션 전반에 걸쳐 중대한 결과를 낳을 수 있다.

반대로 도구와 서비스에 걸쳐 검사를 분산하면 현지 맥락을 보존할 수 있다. 하지만 일관성을 평가하기는 더 어려워질 수 있다. 어느 아키텍처 선호도도 신원, 권한, 결정이 전체 워크플로를 통해 어떻게 이동하는지 이해해야 할 필요성을 없애지는 않는다.

구매자에게 이는 일반적인 아키텍처 우월성 주장보다 운영 적합성이 더 많은 정보를 제공한다는 의미다. 가장 강력한 평가는 조직 자체의 권한 경계와 현실적인 작업을 사용한다. 익숙하지 않은 샘플 프로세스를 중심으로 한 시연은 배포 준비 상태에 관한 증거를 덜 제공한다.

이번 발표는 실질적인 경쟁 이슈를 제기한다. 기업은 AI를 생성하는 시스템과 함께 AI 행동을 제한하는 시스템도 구매하고 있다. 이러한 제한의 가치는 기업이 실제로 사용하는 경로 전반에서 효과를 유지하는지에 달려 있다.

정확한 답변에는 권한 검사 이상의 것이 필요하다

에이전트는 데이터에 정당하게 접근할 수 있으면서도 여전히 오해를 부르는 비즈니스 답변을 만들어낼 수 있다.

Oracle의 Deep Trust 기능에는 자연어 질문을 데이터베이스 쿼리로 변환하는 시스템인 Deep NL2SQL이 포함됩니다. Oracle은 이 시스템이 비즈니스 맥락을 반영하고, 답변 개선을 위한 피드백 및 검증을 지원한다고 설명합니다.

이는 작업이 허용되는지 판단하는 권한 부여와는 다른 책임을 다룹니다. 허용된 쿼리라도 질문을 잘못 이해할 수 있습니다. 유효한 결과라도 원천 데이터가 뒷받침하지 않는 해석을 뒷받침할 수 있습니다.

가령 가장 강력한 고객 관계를 식별해 달라는 가상의 재무 어시스턴트 요청을 생각해 볼 수 있습니다. “가장 강력한”이라는 표현은 매출, 유지율, 수익성 또는 전략적 중요도를 뜻할 수 있습니다. 명확한 확인 없이 하나의 해석을 선택하면, 어떤 레코드도 조회하기 전에 답변의 방향이 정해집니다.

문제가 반드시 계산 오류인 것은 아닙니다. 어시스턴트는 자신이 선택한 지표를 정확히 계산할 수 있습니다. 실패는 그 지표가 비즈니스 질문에 답하는지에 관한 문제입니다.

바로 이 지점에서 Oracle AI 거버넌스는 지식 관리와 맞닿습니다. 조직은 용어, 승인된 지표, 관련 맥락을 지속적으로 관리해야 합니다. 접근을 규율하는 정책은 그러한 정의를 대체할 수 없습니다.

정보 시스템을 비교하는 독자에게는 개인 및 팀 지식의 구분이 유용한 맥락을 제공합니다. 개인의 이해와 조직의 정의는 서로 다른 목적에 기여합니다. 비즈니스 답변에는 해당 업무에 적합한 권위의 원천이 필요합니다.

분석상의 과제는 누구의 해석이 시스템의 일부가 되는지 결정하는 일입니다. 영업 책임자와 재무 책임자는 정당한 이유로 같은 용어를 다르게 사용할 수 있습니다. 유용한 구현은 모든 질문을 하나의 의미에 맞춰 조용히 표준화하기보다 그러한 맥락을 보존해야 합니다.

피드백은 또 다른 책임을 수반합니다. 하나의 답변을 수정하면 특정 상호작용은 개선될 수 있지만, 공유된 정의는 향후 질문에도 영향을 미칩니다. 특히 여러 팀이 같은 개념에 의존하는 경우, 변경 사항은 더 광범위한 영향을 검토해야 합니다.

따라서 구매자는 답이 분명한 질문뿐 아니라 모호성이 포함된 사례를 요구해야 합니다. 불충분하게 규정된 요청에 대한 시스템의 반응은 명확화를 요청하는지, 가정을 밝히는지, 혹은 해석을 확정된 사실처럼 제시하는지를 보여 줍니다.

답변 품질에도 적절한 평가 기준이 필요합니다. 이전 답변이 오래된 정의를 사용했다면, 이전 답변과의 일치는 충분하지 않습니다. 검토 프로세스는 일관성과 정확성을 구분해야 합니다.

이러한 고려 사항이 데이터베이스 통제의 중요성을 낮추는 것은 아닙니다. 이는 청사진이 보안 이상의 범위를 포괄하는 이유를 설명합니다. 동일한 어시스턴트가 두 작업을 수행하더라도, 무단 접근을 막는 일과 의사결정에 활용할 만한 답변을 만드는 일은 별개의 목표입니다.

지식 근로자에게 이는 가장 즉각적인 함의입니다. 비즈니스 가정이 보이지 않는다면, 그럴듯하게 다듬어진 답변도 면밀히 검토해야 합니다. 엔터프라이즈 신뢰에는 권한 경계와 함께 이해 가능한 정의와 추적 가능한 추론이 필요합니다.

Oracle Deep Trust AI Architecture는 이러한 책임을 하나의 이야기로 묶습니다. 그러나 그 효과는 여전히 조직 지식의 품질과 답변 검증에 사용하는 근거에 달려 있습니다.

신뢰 주장은 여전히 배포 근거가 필요하다

이 발표는 Oracle의 설계 입장을 보여 주지만, 고객 배포의 보안성이나 정확성을 독립적으로 입증하지는 않습니다.

AI가 우회할 수 없는 보호 조치에 관한 Oracle의 폭넓은 표현은 구성된 통제 범위 안에서 해석해야 합니다. 이를 전체 엔터프라이즈 시스템이 오용에 면역이라는 주장으로 확대해서는 안 됩니다.

OWASP의 과도한 에이전시 지침은 불필요한 기능, 과도한 권한, 과도한 자율성에서 비롯되는 위험을 지적합니다. 권고 사항에는 기능을 제한하고 관련 사용자의 보안 컨텍스트 내에서 작업을 실행하는 내용이 포함됩니다.

이 지침은 권한을 제한한다는 아키텍처 원칙을 뒷받침합니다. 이는 Oracle 구현에 대한 평가가 아닙니다. 설계 원칙에 부합한다고 해서 특정 제품이나 구성에 대한 근거를 대체하지는 않기 때문에 이 구분은 중요합니다.

신중한 평가는 의도적인 공격뿐 아니라 일상적인 실수도 살펴봐야 합니다. 어시스턴트는 요청을 잘못 읽거나, 잘못된 레코드를 선택하거나, 사용자가 전혀 의도하지 않은 작업을 시도할 수 있습니다. 통제는 이런 상황에서도 이해 가능한 결과를 만들어야 합니다.

신뢰할 수 없는 자료에 포함된 지시를 모델이 따르도록 유도하는 시도인 프롬프트 인젝션은 또 다른 테스트 범주를 추가합니다. 구매자는 모델이 악의적인 지시를 인식하는지뿐 아니라 그러한 시도 이후에도 어떤 권한이 남아 있는지를 검토해야 합니다.

핵심 분석 질문은 실패의 결과입니다. 모델이 잘못 작동할 경우에도 어떤 작업이 여전히 발생할 수 있는가? 이 결과를 평가하는 편이 어시스턴트가 일반적으로 지시를 따르는지 묻는 것보다 더 유용한 근거를 제공합니다.

호의적인 애널리스트 의견에도 맥락이 필요합니다. Oracle이 공개한 아키텍처 신뢰 관점에서 theCUBE Research의 Dave Vellante는 통합 작업을 줄일 가능성을 봅니다. 그는 또한 정책, 검증 및 배포 거버넌스에 대한 책임은 여전히 기업에 있다고 강조합니다.

이러한 의견은 Oracle 자체 사이트에 게재되어 있습니다. 이는 독립적인 비교 테스트가 아니라 공급업체가 선택한, 출처가 명시된 외부 관점입니다. 독자는 발표의 반응을 평가할 때 이 차이를 유지해야 합니다.

이 글에서 검토한 자료는 전반적인 보안이나 답변 정확성을 확립하는 독립적인 비교 벤치마크를 제공하지 않습니다. 이는 이번 출시로부터 도출할 수 있는 결론을 제한합니다. 그렇다고 통제가 효과적이지 않다는 뜻은 아닙니다.

배포 근거에는 시스템이 거부하는 정당한 작업도 포함되어야 합니다. 제한은 원치 않는 작업을 막는 동시에 필요한 업무까지 차단할 수 있습니다. 과도한 거부는 직원들이 수작업 우회 방식을 택하게 해 의도한 프로세스를 약화시킬 수 있습니다.

마찬가지로 성공적인 집행은 조사에 충분한 정보를 남겨야 합니다. 팀은 어떤 ID가 요청을 시작했는지, 어떤 규칙이 적용됐는지, 어떤 결과가 뒤따랐는지를 이해해야 합니다. 이해 가능한 설명이 없는 거부는 다른 운영 부담을 만듭니다.

적절한 결론은 제한적입니다. Oracle은 신뢰할 만한 아키텍처 문제와 이에 대한 조율된 대응을 제시했습니다. 구매자는 여전히 자사 환경에 맞춰 구성된 선택된 구성 요소가 자신들이 우려하는 실패를 해결한다는 근거를 필요로 합니다.

구매자가 2027년 초까지 주목해야 할 사항

다음으로 유용한 근거는 배포 가능성, 측정된 동작, 운영 책임에 관한 것입니다.

첫 번째 신호는 구매자가 사용하려는 구체적 기능의 배포 명확성입니다. 2027년 초까지 고객은 지원 환경, 전제 조건, 제한 사항, 구성 요소 가용성을 포괄하는 정확한 문서를 찾아야 합니다.

이 정보는 폭넓은 청사진을 평가 가능한 구현으로 바꿈으로써 Oracle Deep Trust AI Architecture의 실질적 가치를 강화할 것입니다. 전체 설계가 매력적으로 유지되더라도 요구 사항에 대한 불확실성이 지속되면 도입 계획은 더 까다로워집니다.

이 신호가 중요한 이유는 엔터프라이즈 환경이 서로 다르기 때문입니다. 조직은 제안의 어느 부분이 현재 시스템에 적용되는지 판단할 수 있어야 합니다. 아키텍처 범위에 관한 일반적 설명만으로는 모든 구성 요소 수준의 배포 질문에 답할 수 없습니다.

두 번째 신호는 실패 사례를 포함하는 평가 근거입니다. 유용한 결과는 무단 요청, 잘못된 해석, 허용된 작업, 통제가 거부하는 정당한 업무를 검토할 것입니다. 구매자는 명확히 설명된 설정과 명시적인 한계를 찾아야 합니다.

외부 평가나 문서화된 고객 평가의 근거는 또 다른 일반적 지지 의견보다 신뢰를 더 강화할 것입니다. 좁은 시연에 한정된 결과는 더 제한적인 결론만 뒷받침합니다.

핵심은 평가가 제기된 주장과 부합하는지입니다. 하나의 금지된 요청이 실패한다는 테스트는 관련 없는 작업까지 포괄한다는 사실을 입증하지 않습니다. 정의된 질문 집합에서 나온 정확도 결과가 보편적인 신뢰성 주장으로 확대되어서는 안 됩니다.

세 번째 신호는 시간이 지남에 따라 통제를 운영한 고객 근거입니다. 조직은 정책 변경, ID 업데이트, 예외 처리, 유지 관리를 설명하는 사례를 주시해야 합니다. 이러한 세부 사항은 초기 배포 이후에도 아키텍처가 관리 가능한 상태로 유지되는지를 보여 줍니다.

이 지점에서 경쟁 비교도 더 유용해집니다. Oracle과 AWS 문서는 서로 다른 집행 위치를 설명합니다. 고객 경험은 실제 데이터베이스, 애플리케이션, 외부 서비스 조합 전반에 걸쳐 적용 범위를 유지하는 데 필요한 작업을 명확히 하는 데 도움이 될 수 있습니다.

이러한 신호 중 어느 것도 시장의 승자를 예측할 필요는 없습니다. 이는 아키텍처가 실질적 가치를 제공하는지 평가하는 방법을 제시합니다. 명확한 배포 요구 사항, 관련성 있는 평가, 책임 있는 운영은 Oracle의 주장을 강화할 것입니다.

개발자에게 즉각적인 함의는 작업 생성과 작업 승인를 구분하는 것입니다. 엔터프라이즈 구매자에게는 집행 경계에서 근거를 요구하는 일입니다. 지식 근로자에게는 어떤 정의가 답변을 뒷받침하는지 묻는 일입니다.

어시스턴트의 권한을 확대하기 전에, 팀이 규칙과 결과를 이해하는 워크플로를 선택하십시오. 공급업체에 그 워크플로를 사용해 허용된 요청, 금지된 요청, 모호한 요청을 보여 달라고 요구하십시오. 모델이 잘못 선택했을 때 어떤 일이 일어나는지 검토한 다음, 그에 따른 정책 또는 지식 수정을 누가 책임지는지 확인하십시오. 제품 라벨을 승인으로 간주하지 말고, 근거를 실제 배포에 연결해 두십시오. Oracle Deep Trust AI Architecture는 이러한 논의를 위한 구체적인 출발점을 제공합니다. 이를 통해 정확한 질문을 던지십시오. 어시스턴트가 다음 단계를 잘못 판단했을 때, 어떤 통제가 그 잘못된 단계가 비즈니스 작업으로 이어지는 것을 막는가?