Business Context for AI Agents: 데이터가 정확해도 틀리는 에이전트를 지식 그래프·온톨로지로 바로잡는 SAP의 설계

에이전트가 정확한 데이터를 받고도 틀린 결정을 내리는 이유는 데이터가 아니라 맥락이 없어서입니다. 거래처가 어느 모회사에 속하는지, 지금 결제가 어느 단계인지, 담당자가 왜 문서를 멈춰 뒀는지를 지식 그래프와 온톨로지로 붙여 줘야 합니다. 실제로 쓰려면 부서마다 다르게 부르는 용어부터 하나로 정하고 에이전트에 따로 발급한 신원과 감사 기록을 함께 깔아야 합니다.

요약

VentureBeat는 2026년 10월 22일, SAP가 비용을 낸 후원 기사(Partner content)로 SAP의 연구·혁신 총괄이자 SAP Labs U.S. 대표인 Yaad Oren의 주장을 실었습니다. 질문은 하나입니다. 데이터가 정확하고 빠짐없는데도 에이전트가 틀린 업무 결정을 내리는 이유는 무엇인가. Oren은 범용 LLM에 없는 업무 지식 세 가지를 꼽습니다. 첫째는 엔터티 관계(Entity relationships, 고객·공급업체·제품·재무 기록이 서로 어떻게 이어지는지)입니다. 둘째는 프로세스 맥락(Process context, 이 작업이 결제·주문·출하 가운데 어디쯤인지)입니다. 셋째는 예외(Exceptions, 사람이 시스템에 남기지 않은 판단으로 생긴 변형)입니다. 기사가 든 예는 정상 인보이스입니다. 청구서에는 공급업체가 어느 모회사에 속하는지, 어떤 신용 조건이 붙는지가 보이지 않습니다. 이 관계를 모르는 에이전트는 유효한 결제를 막을 수 있습니다.

Yaad Oren이 꼽은 세 가지 업무 지식. 범용 LLM에는 이 셋이 없다는 것이 출발점

해법으로 Oren은 지식 그래프(Knowledge graph, 엔터티와 관계를 연결한 지도)와 온톨로지(Ontology, 용어마다 하나의 업무 뜻을 고정한 정의 체계)로 회사 전체를 한 지도로 잇자고 말합니다. 다만 둘만으로는 작업 방법까지 정해지지 않습니다. 그래서 결제 조건, 세금·보안 정책, 지역 제한 같은 운영 맥락을 플랫폼이 함께 줘야 한다고 봅니다. 표에 담긴 업무 데이터는 RPT-1.6과 TabPFN-3.5 Plus 같은 표 전용 모델(Tabular foundation model)이 맡습니다. 에이전트가 답을 넘어 행동하기 시작하면 고유 신원, 범위 제한 권한, 감사 기록이 필요해집니다. SAP는 이를 Model, Platform, Agents, User experience의 4계층으로 정리하고 업무 이해가 모이는 곳으로 Platform 계층을 꼽습니다. 아래에서는 여섯 가지 메커니즘을 풀고 매입 인보이스 결제 판단 에이전트를 예로 그래프 스키마와 결정 JSON, 6주 파일럿 계획을 덧붙입니다.

원문의 4계층. 업무 이해가 모이는 곳은 Platform 계층이라는 것이 SAP의 설명

핵심 메커니즘

Entity Relationships: 이름과 금액 너머의 연결

무엇인가. 거래 한 건을 판단할 때 그 거래에 걸린 다른 엔터티까지 함께 보는 능력입니다. Oren은 고객 이름과 총액만으로 데이터를 꺼내서는 부족하다고 말합니다.

어떻게 작동하나. 에이전트가 고객 A를 조회하면 지식 그래프는 연결된 노드를 함께 돌려줍니다. 원문이 든 항목은 그 고객의 판매 주문 수, 만족도, 지연 출하 건수, 주문을 만든 생산 공장입니다. 에이전트는 이 묶음을 근거로 판단하므로 이름이 같은 다른 고객과 헷갈리지 않습니다. 금액만 보고 위험을 판정하는 일도 줄어듭니다.

언제 쓰나. 결정이 여러 시스템의 기록에 걸쳐 있을 때 씁니다. 결제 보류, 신용 한도 조정, 납기 약속이 그렇습니다. 한 테이블 안에서 끝나는 조회라면 그래프 없이 SQL로 충분합니다.

작은 예시(가상). 고객 A의 결제가 30일 늦었습니다. 금액만 보면 위험 고객입니다. 그래프를 보면 같은 기간 이 고객 주문의 지연 출하가 5건이었고 모두 같은 공장에서 나왔습니다. 결제 지연의 원인이 우리 쪽 출하일 수 있다는 근거가 생깁니다.

원문이 든 예: 고객 이름과 총액만으로는 부족하고 주문·만족도·지연 출하·생산 공장까지 이어져야 함

Ontology: ‘invoice’ 한 단어에 뜻 하나

무엇인가. 용어마다 업무상 뜻을 하나로 정하고 그 뜻을 시스템과 데이터 소스가 달라도 그대로 유지하게 하는 정의 체계입니다. Oren의 표현을 빌리면 회사 데이터 전체에 하나의 진실과 하나의 목소리를 주는 장치입니다.

어떻게 작동하나. 원문의 예에서 ‘invoice’는 부서에 따라 고객이 낸 대금, 출장비 정산, 공급업체 청구서를 뜻합니다. 지식 그래프가 모든 인보이스를 연결해도 이 뜻이 섞여 있으면 에이전트는 서로 어긋난 신호를 받습니다. 온톨로지는 세 뜻을 서로 다른 개념으로 나누고 각 시스템의 필드가 어느 개념에 속하는지 연결합니다. 에이전트는 단어가 아니라 개념 ID로 데이터를 찾습니다.

언제 쓰나. 직원이 수십만 명인 글로벌 기업처럼 부서와 시스템이 많을수록 필요합니다. Oren은 이런 회사에서는 기록이 서로 연결되고 같은 언어로 말해야 한다고 봅니다. 한 부서가 한 시스템만 쓰는 작은 범위라면 용어 사전 한 장으로도 됩니다.

작은 예시(가상). 재무팀 에이전트가 “이번 달 미지급 invoice”를 물으면 SupplierInvoice만, 출장 담당 에이전트는 TravelReimbursement만 집계합니다. 같은 단어로 물어도 숫자가 섞이지 않습니다.

원문 예: 'invoice'가 부서마다 고객 대금·출장비 정산·공급업체 청구서를 뜻함. 온톨로지는 시스템이 달라도 같은 뜻을 유지

Process Context와 Exceptions: 지금 어느 단계이고 왜 멈췄나

무엇인가. 기업의 작업은 모두 결제, 주문, 출하, 입사 처리 같은 프로세스에 속합니다. 프로세스 맥락은 에이전트에게 지금 몇 번째 단계인지, 앞에서 무슨 일이 있었고 다음에 무엇이 오는지를 알려 줍니다. 예외는 사람이 판단으로 승인하거나 미룬 탓에 정해진 흐름에서 벗어난 경우입니다. 이 판단은 업무 시스템에 기록되지 않는 일이 많습니다.

어떻게 작동하나. 에이전트는 문서 상태만 보지 않고 프로세스 안에서 위치를 확인합니다. 멈춘 문서를 만나면 실패인지 예외인지를 가립니다. Oren은 AI가 예외를 알아보고 관리하며 그 예외를 답이나 활동에 쓸 수 있는 맥락으로 돌려줘야 한다고 말합니다. 그의 말로는 “Not everything obeys the letter of a process.”(모든 일이 프로세스 문구대로 움직이지는 않는다)입니다.

언제 쓰나. 사람의 재량이 큰 단계가 있는 프로세스에서 씁니다. 예산 배분, 예외 승인, 분쟁 처리가 그렇습니다. 완전 자동 처리 구간에서는 단계 정보만으로 충분합니다.

Process context는 지금 단계와 앞뒤를, 예외 인식은 멈춘 이유를 알려 줌. 단계 이름은 가상 예시

Operational Context: 뜻을 맞춘 다음에 필요한 작업 규칙

무엇인가. 지식 그래프와 온톨로지가 무엇이 무엇인지를 정한다면, 운영 맥락은 이 작업을 어떤 조건에서 어떻게 하는지를 정합니다. 원문은 공유된 뜻만으로는 에이전트를 일부 지점까지만 데려간다고 말합니다.

어떻게 작동하나. 플랫폼이 서비스 수준 약정(SLA)과 결제 조건, 세금·보안 정책, 지역 제한, 데이터 익명화 규칙을 작업 시점에 에이전트에게 넘깁니다. SAP의 Business AI Platform(BAIP, SAP가 데이터와 업무 맥락을 통제된 환경에 모으는 플랫폼)이 이 역할을 맡습니다. BAIP의 지식 그래프는 고객, 공급업체, 자산, 제품, 조직 구조, 업무 프로세스 사이의 관계를 담습니다. 이렇게 만든 맥락은 여러 에이전트가 다시 씁니다.

언제 쓰나. 같은 결정이라도 나라, 계약, 데이터 등급에 따라 달라지는 업무에 씁니다. 해외 법인 결제와 개인정보가 섞인 고객 응대가 대표적입니다.

원문: 그래프와 온톨로지는 뜻을 맞추고, 작업 방법은 플랫폼이 주는 운영 맥락이 정함

Tabular Foundation Model: 표 데이터를 표 그대로 읽는 모델

무엇인가. 행과 열로 된 관계형·거래형 데이터를 처리하도록 미리 학습한 모델입니다. 원문은 범용 LLM이 자연어용으로 설계됐고 표에 저장된 업무 데이터는 그 대상이 아니었다고 설명합니다. Oren은 기업 내부 데이터가 근본적으로 관계형·거래형이므로 모델이 그 구조를 원래부터 이해해야 한다고 봅니다.

어떻게 작동하나. SAP가 내놓은 모델은 RPT-1.6(Relational Pre-trained Transformer)과 TabPFN-3.5 Plus입니다. TabPFN-3.5 Plus는 원문이 SAP의 프런티어 AI 연구소라고 소개한 Prior Labs의 모델입니다. 두 모델은 결측값, 섞인 데이터 타입, 고유값이 아주 많은 필드처럼 지저분한 정형 데이터를 다루도록 만들어졌습니다. SAP AI Core의 tabular orchestration 기능이 실행 시점에 어떤 맥락을 넣을지 고르고 데이터 접근을 처리합니다. 그래서 예측 결과를 실제 업무 흐름에 바로 넣을 수 있습니다.

언제 쓰나. 숫자나 분류를 예측해야 하는 판단에 씁니다. 원문은 구체적인 예측 용례를 들지 않습니다. 아래 기술 디테일에서는 지급 지연 확률을 가상 예시로 씁니다. 사람에게 근거를 설명하는 일은 여전히 LLM이 맡습니다.

원문: 업무 데이터는 관계형·거래형이라 그 구조를 원래부터 이해하는 모델이 필요. 왼쪽 설명은 원문 취지를 풀어 씀

Scoped Identity와 Audit Trail: 행동하는 에이전트의 울타리

무엇인가. 에이전트가 질문에 답하던 단계를 지나 직접 행동하면 위험의 크기가 달라집니다. 틀린 답은 무시하면 그만입니다. 잘못 막힌 결제, 거절된 주문, 잘못 붙은 신용 위험 표시는 공급업체와 고객, 다음 프로세스로 빠르게 번집니다. Oren은 업무 맥락이 지식뿐 아니라 경계도 준다고 말합니다. 그래서 답은 늘 다시 따져 봐야 한다고 봅니다.

어떻게 작동하나. BAIP에서 에이전트는 따로 발급한 고유 신원(identity)과 범위를 제한한 권한으로 움직입니다. 감사 기록(audit trail)에는 누가 행동했는지, 권한 범위가 어디까지였는지, 무엇을 했는지가 남습니다. AI 기능은 윤리·위험 검토를 거칩니다. 에이전트는 기능마다 지역 정책, 개인정보 법, 규제에 맞는지 따로 평가받습니다. 에이전트가 끌어오는 맥락에도 관련 정책과 보안 고려 사항이 들어가야 합니다.

원문의 BAIP 거버넌스: 신원·권한을 먼저 정하고 모든 행동을 audit trail에 남김

통념과 다른 주장

흔히 이렇게 봅니다데이터 품질을 높이고 빠짐없이 모으면 에이전트도 맞는 결정을 내린다고 봅니다.

저자는 이렇게 봅니다데이터가 정확하고 완전해도 관계, 프로세스 단계, 예외를 모르면 에이전트는 틀린 결정을 내립니다.

근거청구서만 보면 공급업체의 모회사 관계와 신용 조건이 드러나지 않아 정상 결제를 막을 수 있다는 예를 듭니다.

흔히 이렇게 봅니다지식 그래프와 온톨로지를 깔면 에이전트가 업무를 이해하게 된다고 봅니다.

저자는 이렇게 봅니다둘은 뜻을 맞춰 줄 뿐이고 작업을 어떻게 할지는 알려 주지 않습니다. 운영 맥락과 거버넌스가 함께 있어야 합니다.

근거SLA와 결제 조건, 세금·보안 정책, 지역 제한, 익명화 규칙을 플랫폼이 따로 공급해야 한다고 설명합니다.

흔히 이렇게 봅니다범용 LLM 하나면 문서든 표든 업무 데이터를 모두 다룰 수 있다고 봅니다.

저자는 이렇게 봅니다표에 담긴 관계형·거래형 데이터는 그 구조를 원래부터 이해하는 표 전용 모델이 맡아야 합니다.

근거SAP가 결측값과 섞인 타입을 다루도록 만든 RPT-1.6과 TabPFN-3.5 Plus를 따로 내놓은 점을 듭니다.

세 가지 통념과 원문 주장의 대비

저자가 든 사례

정상 인보이스의 결제 차단

구분	내용
상황	에이전트가 공급업체 인보이스 결제를 판단합니다. 청구서에는 그 공급업체가 어느 모회사에 속하는지, 어떤 신용 조건이 적용되는지가 나오지 않습니다.
한 일	원문은 엔터티 관계를 지식 그래프로 연결해 에이전트가 판단 전에 읽게 하라고 제안합니다.
결과	맥락이 없으면 정확한 데이터로도 유효한 결제를 막을 수 있습니다. 실제 발생 건수와 금액은 원문에서 밝히지 않았습니다.
연결	Entity Relationships

원문이 든 위험 시나리오. 실제 발생 건수나 금액은 원문에서 밝히지 않음

Parked document: 담당자가 자리를 비운 케이터링 인보이스

구분	내용
상황	회사 행사가 끝나면 controller(재무 관리 담당자)가 케이터링 인보이스를 여러 예산으로 나눠 배분해야 다음 단계로 넘어갑니다. SAP는 이렇게 멈춘 문서를 parked document라고 부릅니다.
한 일	Oren의 예입니다. controller가 휴가나 육아휴직 중이라면 프로세스를 지켜보던 에이전트는 멈춘 인보이스를 심각한 지연으로 볼 수 있습니다. 더 넓은 업무 맥락이 있으면 담당자 부재를 알아보고 예외로 다룹니다.
결과	프로세스 실패가 아닌 예외로 분류합니다. 원문은 이를 가능성으로 제시했고 실제 오판 기록은 밝히지 않았습니다.
연결	Process Context와 Exceptions

SAP가 parked document라 부르는 상황. 원문은 가능성으로 제시

고객 질문 하나가 재무까지 번지는 경우

구분	내용
상황	고객 정보, 예를 들어 마케팅 캠페인과 할인을 묻는 질문은 곧 납기(공급망)로, 다시 결제(재무)로 이어집니다.
한 일	Oren은 지식 그래프와 온톨로지로 모든 것을 하나의 업무 지도로 연결하는 데서 가치가 나온다고 말합니다.
결과	원문은 수치를 밝히지 않았습니다. 재무 에이전트와 공급망 에이전트가 같은 표현을 각자 다시 만들지 않고 함께 쓰는 구조가 목표입니다.
연결	Ontology, Operational Context

원문 예: 고객 정보 질문 하나가 공급망을 거쳐 재무로 이어짐. 그래서 전사를 한 지도로 이어야 함

기술 디테일: 매입 인보이스 결제 에이전트에 옮기려면

아래는 원문의 메커니즘을 매입 인보이스 결제 보류 판단 에이전트 하나에 옮길 때 필요한 것을 새로 정리한 내용입니다. 필드명, 숫자, 설정값은 모두 가상 예시입니다.

Entity Relationships를 돌리려면 그래프 스키마를 결제 판단에 필요한 만큼만 먼저 잡습니다. 처음부터 전사 그래프를 만들지 않습니다. 노드는 Vendor, ParentCompany, CreditAgreement, PurchaseOrder, GoodsReceipt, SupplierInvoice, Plant 일곱 개로 시작합니다. 엣지는 BELONGS_TO(Vendor→ParentCompany), COVERED_BY(Vendor→CreditAgreement), BILLS(SupplierInvoice→PurchaseOrder), RECEIVED_AS(PurchaseOrder→GoodsReceipt), SHIPS_FROM(PurchaseOrder→Plant)입니다. 원천은 ERP 거래처 마스터, 계약 시스템, 구매·입고 테이블입니다. 모회사 관계는 거래처 마스터에 없는 경우가 많으니 외부 기업정보 데이터와 맞춰 보고 확인 날짜를 엣지 속성(verified_at)으로 남깁니다.

{
  "node": "Vendor:V-10482",
  "edges": [
    {"type": "BELONGS_TO", "to": "ParentCompany:P-221", "source": "vendor_master", "verified_at": "2026-10-01"},
    {"type": "COVERED_BY", "to": "CreditAgreement:CA-77", "terms": "net60", "limit": 500000, "currency": "USD"}
  ]
}

Ontology를 돌리려면 용어 사전을 데이터로 관리합니다. 항목마다 term_id, label, definition, owner_dept, source_fields(어느 시스템의 어느 필드가 이 개념인지), synonyms, not_to_confuse_with를 둡니다. ‘invoice’ 예라면 SupplierInvoice, CustomerPayment, TravelReimbursement를 따로 등록하고 서로를 not_to_confuse_with로 묶습니다. 에이전트 프롬프트에는 단어 대신 term_id를 넣고 검색 도구는 term_id로만 필터합니다. 정의가 바뀌면 버전을 올리고 에이전트 결정 기록에 그때의 사전 버전을 같이 남깁니다.

Process Context와 Operational Context를 돌리려면 결정 전에 맥락을 정해진 순서로 읽게 합니다. 순서는 엔터티 관계 → 용어 확정 → 현재 프로세스 단계 → 운영 규칙(결제 조건, 지역 제한, 보안 등급) → 예외 신호입니다. 각 단계는 도구 호출 하나로 나누고 결과가 비면 다음 단계로 가지 않고 “맥락 부족”으로 사람에게 넘깁니다. 이렇게 해야 근거가 빈 채로 결정하는 일이 막힙니다.

새로 작성: 에이전트가 결정 전에 맥락을 읽는 순서(가상 예시)

결정은 구조화 출력으로 받습니다. 모델은 decision(pay, hold, escalate 중 하나), confidence(0~1), evidence(참조한 노드·엣지 ID 목록), policy_refs(적용한 결제 조건·규칙 ID), exception_flag와 exception_reason, ontology_version을 채운 JSON만 내게 합니다. temperature는 0으로 두고 같은 건을 3회 돌려 decision이 한 번이라도 다르면 escalate로 바꿉니다. evidence가 비어 있는 hold는 무효로 처리합니다.

{
  "invoice": "SupplierInvoice:SI-55310",
  "decision": "pay",
  "confidence": 0.86,
  "evidence": ["BELONGS_TO:V-10482>P-221", "COVERED_BY:V-10482>CA-77", "RECEIVED_AS:PO-9011>GR-3302"],
  "policy_refs": ["net60", "region:KR"],
  "exception_flag": false,
  "ontology_version": "v1.3"
}

“답을 늘 다시 따져 보라”는 원칙은 검증 패스로 구현합니다. 첫 결정이 hold나 거절이면 두 번째 호출이 반대 근거만 찾게 합니다. 예를 들면 모회사 신용 조건, 같은 거래처의 최근 정상 지급 이력, 입고 완료 여부입니다. 반대 근거가 하나라도 나오면 사람 검토로 보냅니다. 결제를 막는 쪽의 오판이 거래처 관계에 주는 비용이 크기 때문에 막는 결정에만 이 패스를 겁니다.

Exceptions를 잡으려면 시스템 밖의 판단을 신호로 끌어옵니다. parked document 사례처럼 담당자 부재가 원인인 멈춤은 HR 근태(휴가·휴직), 결재 위임 설정, 조직도에서 읽을 수 있습니다. 문서가 정해진 기간(예: 5영업일) 넘게 멈추면 담당자 부재 여부를 먼저 조회합니다. 부재면 exception_reason에 “approver_absent”와 복귀 예정일을 적고 위임자에게 알립니다. 부재가 아니면 지연으로 올립니다. 근태 정보는 개인정보이므로 에이전트에는 부재 여부와 복귀일만 넘기고 사유(육아휴직 등)는 넘기지 않습니다.

Tabular Foundation Model은 예측만 맡기고 설명은 LLM에 맡깁니다. 지급 지연 확률이나 중복 청구 가능성 같은 숫자는 거래처·금액·조건·이력 열을 그대로 표 모델에 넣어 받습니다. 표를 텍스트로 풀어 LLM에 넣는 방식과 같은 홀드아웃 데이터(최근 3개월)로 비교해 더 나은 쪽을 고릅니다. LLM은 표 모델의 숫자와 그래프 근거를 묶어 결재자가 읽을 세 줄 설명만 씁니다.

새로 작성: 숫자 예측은 표 모델, 설명은 LLM이 맡는 분업(가상 예시)

Scoped Identity와 Audit Trail은 에이전트마다 서비스 계정을 따로 둡니다. 결제 에이전트 계정은 인보이스 상태를 hold로 바꿀 수만 있고 지급 실행이나 거래처 마스터 수정 권한은 없습니다. 감사 로그에는 agent_id, permission_scope, action, target, evidence, decision_json_hash, timestamp, approved_by를 남깁니다. 원문이 말한 “누가, 어떤 권한 범위로, 무엇을” 세 가지를 필드로 옮긴 것입니다.

실패하는 경우와 대응. 모회사 관계가 오래돼 틀리면 근거 자체가 틀립니다. verified_at이 180일을 넘은 엣지는 근거로 쓰지 않고 재확인 대기열에 넣습니다. 온톨로지에 없는 새 용어가 들어오면 에이전트가 추측하지 않고 “미등록 용어”로 멈추게 합니다. 표 모델 입력 열이 바뀌면 예측이 조용히 틀어지므로 열 목록을 계약처럼 고정하고 바뀌면 배포를 막습니다.

현업 실행 디테일: 누가, 언제, 무엇을

역할	담당 예	하는 일
현업 스폰서	재무 담당 임원(CFO 조직)	대상 업무 한정, 판정 기준 승인, 부서 간 용어 합의 주재
용어 오너	재무·구매·출장 관리 담당자 각 1명	‘invoice’ 류 용어 10개 정의와 서명, 변경 승인
데이터 엔지니어	IT 데이터팀 1~2명	거래처·계약·구매·입고 데이터로 그래프 적재, verified_at 관리
AI 엔지니어	AX 추진팀 1명	조회 순서, 결정 JSON, 검증 패스, 반복 실행 구현
결재 담당	매입 채무 담당자 2~3명	섀도 운영 중 에이전트 판단과 실제 판단 대조
감사·보안	내부통제·정보보안	권한 범위와 감사 로그 필드 승인, 근태 정보 범위 승인

시작 전 준비물. 최근 6개월 매입 인보이스와 결제 보류·해제 이력, 거래처 마스터와 모회사 매핑, 신용·결제 조건 계약 목록, 결재 위임 규칙, 부서별로 ‘invoice’를 어떻게 부르는지 적은 용어 목록이 필요합니다. 결제를 잘못 막았거나 늦게 풀어 문제가 됐던 사례 20건 정도를 함께 모으면 평가 기준이 됩니다.

가상 예시 일정(새로 작성). 원문은 일정과 기간을 밝히지 않음

기간	할 일	산출물
1~2주	대상 업무를 매입 인보이스 결제 보류 판단 하나로 한정. 부서별 용어 인터뷰 후 용어 10개 정의	서명된 용어 사전 v1, 범위 문서
3~4주	그래프 7개 노드 적재, 결정 JSON과 조회 순서 구현, 과거 20건으로 재현 시험	그래프 스냅숏, 재현 결과표
5주	섀도 운영: 에이전트는 판단만 기록하고 실제 결제는 사람이 기존대로 처리	일치·불일치 로그
6주	판정 회의, 확대 범위 결정	진행 여부 결정 메모

현업에 물을 것.

결제를 보류할 때 청구서 말고 어떤 화면과 문서를 더 봅니까?
같은 ‘invoice’라는 말을 다른 부서는 어떤 뜻으로 씁니까? 그 차이 때문에 숫자가 틀린 적이 있습니까?
담당자가 자리를 비워 멈춘 문서는 지금 누가 어떻게 알아챕니까?
에이전트가 절대 바꾸면 안 되는 상태나 필드는 무엇입니까?

진행 판정 기준(예시). 섀도 운영에서 다음을 모두 채우면 다음 단계로 갑니다. 에이전트와 결재 담당 판단 일치율 90% 이상, 정상 결제를 막자고 한 오판 0건, evidence가 빈 결정 0건, 담당자 부재로 멈춘 문서를 예외로 분류한 비율 80% 이상입니다. 기준은 섀도 운영 전에 스폰서가 승인합니다.

AX 적용 제언. 고객사에서는 지식 그래프 구축 프로젝트로 시작하지 말고 결정 하나로 시작하는 편이 좋습니다. 매입 인보이스 결제 보류처럼 잘못 막으면 거래처가 바로 알아채고 효과를 재기 쉬운 결정이 맞습니다. 첫 투자는 모델이 아니라 부서 간 용어 합의에 둡니다. ‘invoice’ 하나의 뜻을 맞추는 회의가 이 설계에서 가장 오래 걸리는 일이고 IT가 대신할 수 없습니다. 그래서 스폰서는 재무 조직에 둡니다. 첫 에이전트가 쓴 그래프와 용어 사전은 다음 에이전트(채권 회수, 공급망 납기)가 다시 쓰게 설계합니다. 원문이 Platform 계층을 강조한 이유가 이 재사용에 있습니다. 근태·위임 정보 연결은 HR·법무 검토가 필요하므로 1주차에 요청을 넣어 둡니다.

새로 작성: 고객사 적용 순서 제언(가상 예시)

원문 사례

항목	내용
게재	VentureBeat, 2026.10.22, VB Staff. SAP 후원 콘텐츠(Partner content, presented by SAP)
화자	Yaad Oren, SAP Global Head of Research and Innovation, SAP Labs U.S. Managing Director
핵심 주장	정확한 데이터만으로는 부족하고 업무 구조(관계·프로세스·규칙)를 알아야 에이전트가 맞는 결정을 내림
세 가지 업무 지식	Entity relationships, Process context, Exceptions and variations
용어 예	‘invoice’가 부서마다 고객 대금, 출장비 정산, 공급업체 청구서를 뜻함
운영 맥락	SLA·결제 조건, 세금·보안 정책, 지역 제한, 데이터 익명화 규칙
모델	RPT-1.6(Relational Pre-trained Transformer), TabPFN-3.5 Plus(Prior Labs), AI Core tabular orchestration
거버넌스(BAIP)	고유 신원, 범위 제한 권한, audit trail, 윤리·위험 검토, 기능별 지역 정책·개인정보 법 평가
사례	정상 인보이스 결제 차단 위험, parked document(케이터링 인보이스와 controller 부재)
4계층	Model(표 전용 모델), Platform(BAIP), Agents(재무·공급망 Joule Agents), User experience(텍스트·음성·동적 시각화)
수치	성과 수치는 원문에 없음

핵심 개념

Knowledge graph: 엔터티(고객, 공급업체, 주문 등)를 노드로, 그 사이 관계를 엣지로 이은 데이터 구조. 에이전트가 한 건을 볼 때 연결된 것까지 함께 읽게 합니다.
Semantic layer: 원천 시스템의 필드 위에 업무 용어와 정의를 얹은 층. 원문은 Platform 계층의 구성 요소로 듭니다.
BAIP: SAP Business AI Platform. 데이터와 업무 맥락을 통제된 환경에 모으고 에이전트를 만들고 관리하는 SAP의 플랫폼입니다.
Parked document: SAP에서 다음 단계로 넘어가지 않고 보류된 문서. 원문 예에서는 controller의 예산 배분을 기다리는 인보이스입니다.
Controller: 회계·예산 관리를 맡는 재무 담당자. 원문 예에서 케이터링 비용을 여러 예산으로 나눕니다.
Joule Agents: SAP가 재무·공급망 업무에 내놓은 에이전트. 원문의 4계층에서 Agents 계층에 놓입니다.
SAP AI Core: SAP의 AI 실행 환경. 원문은 여기의 tabular orchestration이 실행 시점에 맥락을 고르고 데이터 접근을 처리한다고 설명합니다.

내 메모

TODO: 내 생각 추가

원문: VB Staff, 「AI agents can have accurate data, and still make the wrong business decision」(VentureBeat, 2026.10.22). 이 기사는 SAP가 비용을 낸 후원 콘텐츠(Partner content, presented by SAP)이며 SAP 제품에 관한 설명은 SAP 측 주장입니다. 요약·메커니즘·통념과 다른 주장·사례·원문 사례 표는 원문의 내용을 AX Review가 다시 정리했습니다. 기술·현업 디테일, 그래프 스키마와 JSON 예시, 일정·판정 기준, 인포그래픽은 새로 작성했으며 그 안의 필드명, 용어 ID, 숫자는 가상 예시입니다. 원문 전체는 VentureBeat에서 볼 수 있습니다.