Graft AI

Graft AI는 인터페이스에 연결해 시각, 접근성 신호, UI 상태를 활용하여 특정 시점에 화면에 실제로 무엇이 있는지 파악한다. 그래서 API가 없는 시스템도 에이전트가 호출할 수 있게 된다. 녹색 화면 메인프레임이나 고집스러운 데스크톱 도구를 마주한 팀에게, 바로 이 부분이 나머지 전부를 가능하게 한다. API가 없다고? 걸림돌이 아니다.

각 워크플로는 명확한 스키마, 타입이 지정된 입력, 정의된 출력을 가진 버전 관리된 도구로 컴파일된다. 에이전트는 고객 ID, 금액, 통화를 담아 create_invoice를 호출하고 무엇을 돌려받을지 안다. 여기서는 버전 관리가 중요하다. UI 가정이 바뀌면 Graft는 영향받는 동작을 분리해 전체가 흔들리게 두는 대신 재테스트 대상으로 표시한다.

역할, 경계, 승인은 도구의 일부이며 나중에 덧붙이는 것이 아니다. 쓰기 동작은 실행 전에 승인을 요구할 수 있어서 에이전트가 운영 데이터를 조용히 바꾸지 않는다. 효과는 미리 명시된다. 예를 들어 생성 동작은 정확히 레코드 하나를 만든다는 식이며, 이는 영향 범위를 작게 유지한다. 영향 범위는 작게. 핵심은 거기에 있다.

모든 동작은 출처 시스템에 묶인 증거를 돌려준다. 예를 들어 출처 레코드와 생성된 것의 ID다. 이것이 에이전트 동작을 감사 가능하게 만든다. 효과가 실제 시스템에서 일어났는지를, 모델이 자기 생각에 한 일에 대한 요약을 믿는 대신 확인할 수 있다. 신뢰보다 증거다.

여기서 거버넌스란 역할, 경계, 승인, 감사 흔적이 모두 같은 하나의 동작을 설명한다는 뜻이다. 도구 계약에 AI 에이전트 거버넌스를 내장하는 이유가 바로 이것이다. 승인된 동작에는 정의된 효과, 요구되는 승인자, 무엇이 바뀌었는지에 대한 기록이 있다. 감사자는 분위기가 아니라 구체적인 사실을 받는다.

Graft AI는 각 단계를 완전한 맥락과 함께 기록하고, 실행되는 환경의 역할과 제약을 존중한다. 에이전트가 무엇을 만들고, 갱신하고, 취소했는지 그리고 언제 했는지를 계속 볼 수 있다. 매번 완전한 맥락이다. 감사자에게 설명할 책임이 있는 사람에게, 이것이 데모와 실제로 배포할 만한 것의 차이다.

보안 통제는 위험과 무관하게 모든 동작을 똑같이 다루는 일괄 정책으로 적용되는 것이 아니라, 워크플로와 환경에 맞춰 평가된다. 왜 중요할까. 급여 워크플로와 지원 조회가 같은 안전장치를 받을 필요는 없기 때문이다. 데이터 처리도 범위를 좁혀서 입력, 증거, 로그를 평가 대상 워크플로로 제한한다. 환경에 엄격한 데이터 규칙이 있다면, 이 워크플로 단위 접근이 일반 클라우드 커넥터보다 정당화하기 쉽다.