팀 AI 워크플로우를 조직 AI 운영체계로 확장하는 방법

In Part 1, we summarized when an ontology and knowledge graph are needed for an AI agent.

In Part 2, we looked at the roles of Ontology, Knowledge Graph, RAG, GraphRAG, SHACL, and SPARQL from an architectural perspective.

Now, in Part 3, we will get into more practical questions.

So where should organizations start?

There is one most important principle here.

Don’t start with a company-wide KG, but start with one core task you want to automate.

Organizational AI automation is not a project that creates a huge knowledge graph at once. This is the process of selecting a repetitive task, organizing the concepts and questions required for that task, and adding a thin semantic layer on top of the existing DB, document, ticket, and API.

In this article, we outline a step-by-step strategy for extending team AI workflows to organizational AI operating systems.

Date of analysis: 2026-05-01 Key references: OpenAI/Anthropic agent design material, W3C R2RML/SPARQL/SHACL, Microsoft GraphRAG Scope of analysis: Not every detailed implementation of an enterprise-wide architecture, but a practical roadmap to start small and scale organizationally

Key takeaways

• The organizational AI operating system is not a project to create company-wide KG all at once. You should start with a minimal ontology on one core task.
• A good first task should be one where the frequency of repetition, risk, data connectivity, need for authority verification, and ROI are all visible.
• By definingCompetency Questionfirst, we can keep the ontology scope small.
• There is no need to move all existing RDBs, document stores, and ticket systems to Graph DB. Connect to R2RML, SPARQL, API, ETL, and document extraction pipelines.
• The expansion order is realistic: workflow automation to team knowledge structuring to common business concept definition to minimum ontology to task KG to organizational AI operating system.

1. Why is it easy to fail if you start with warrior KG?

When talking about organizational-level AI automation, many teams immediately think of this picture.

1# Example structure2Enterprise data integration3to transcription ontology design4to build a company-wide knowledge graph5to Shared by all Agents6to Completion of organizational AI operating system

In theory, it's a great picture. However, in practice it is dangerous.

Starting with Warrior KG, we have the following problem:

The goal of AI automation is not “create nice graphs.” The goal is to get work done faster and safer.

So your starting point should be one task, not all of your data.

Practice Principles Before creating an enterprise KG, you must first decide what questions the AI ​​Agent should answer and what actions it should safely execute in a specific task.

OpenAI and Anthropic's agent design materials also recommend an approach that starts from a simple and combinable structure rather than a complex framework. The same goes for organization KG. Rather than modeling everything from scratch, start by creating the semantic layer needed to reduce automation failures.

2. Criteria for choosing your first task

The first task selection determines the success or failure of the entire project.

A good first task satisfies the following conditions:

1# Example structure2It repeats.3Connect multiple systems.4There are work rules.5There is a cost to failure.6But not too fatal.7Performance can be measured.

For example, you might be a candidate for the following jobs:

The most recommended type for your first job is Medium Risk Job.

If it is too simple, the value of the ontology/KG will not be revealed. If it is too risky, the security, legal, and audit requirements will become excessive before automation can begin.

A good example is new customer onboarding.

1# Example structure2There is customer information.3There is a contract status.4There is a security screening.5There is a person in charge.6There is a checklist.7There are policies for each industry.8Execution log is required.9However, most actions can be performed after approval.

This task is complex enough to demonstrate the value of Ontology and KG, but without requiring fully automated execution from scratch.

3. How to determine scope with Competency Question

The reason the ontology project is growing is because it starts with “what to model.”

A better starting point is “What questions should be answered?”

In ontology design, this is commonly calledCompetency Question. Simply put, this is a list of key questions this model should be able to answer.

Customer onboarding tasks include:

1# Example structure2What is this customer's contract status?3What industry does this customer belong to?4What onboarding checklist applies to this customer?5Did you pass the security screening?6Who is the responsible CSM?7Who has permission to execute the Start Onboarding action?8What is the supporting document for this action?9What conditions must be met for this task to be completed?

Once these questions are established, fewer concepts are needed.

The advantages of this approach are clear.

1# Example structure2Do not create concepts that are not necessary for the question.3It is directly linked to work performance.4PoC evaluation criteria become clear.5Easy for domain experts to review.

Practical Tips Don’t lay out “all of our company’s concepts” in your first ontology meeting. First, organize “10 questions this Agent must answer”.

4. Design a minimal ontology

Once the competency question is determined, a minimal ontology can be designed.

There is no need to create a perfect OWL model from scratch. First, organize business objects and relationships into a human-readable form.

Here's an example customer onboarding:

1# Example structure2Class:3- Customer4- Contract5- SecurityReview6- OnboardingChecklist7- Person8- Team9- Role10- Permission11- Policy12- Document13- Evidence14- Decision15- Action16- System

A relationship can start like this.

1# Example structure2Customer hasContract Contract3Customer hasSecurityReview SecurityReview4Customer assignedTo Person5Customer belongsToIndustry Industry6Contract hasStatus ContractStatus7Person belongsTo Team8Person hasRole Role9Role grants Permission10Action requires Permission11Action constrainedBy Policy12Decision basedOn Evidence13Evidence refersTo Document14System owns Data

At this stage it is helpful to distinguish between three things:

The minimal ontology must satisfy the following conditions:

1# Example structure2Can answer business questions.3Reduce differences in terminology between teams.4Can be mapped with existing system data.5Verification rules can be added.6Don't include too many exceptions in the first place.

Naming rules are also established early on.

Even for small models, it is a good idea to establish naming rules early on.

Naming may seem trivial, but it becomes important later when multiple teams reuse the same model.

5. Connect existing DB, documents, tickets, and API

Creating an ontology does not mean that all existing systems must be moved to Graph DB.

In practice, it is more realistic to maintain the existing system and add a layer of meaning.

1# Example structure2CRM3ERP4Jira5Confluence / Notion6Slack7document storage8In-house approval system9↓10Mapping / Extraction / API / R2RML11↓12Business knowledge graph or virtual graph view

W3C R2RML is a language for mapping relational databases to RDF datasets. Enables existing relational data to be viewed in the RDF data model with a structure and vocabulary chosen by the map author.

SPARQL is also explained so that you can query not only data stored as RDF, but also data that looks like RDF through middleware.

In other words, the introduction strategy is not to “migrate everything to Graph DB” but to choose one of the following.

Document linking is especially important for evidence management.

Simply dividing unstructured documents into chunks may not be enough.

Because documents are the foundation for organizational automation.

1# Example structure2Document3→ containsClaim → Claim4→ supportsDecision → Decision5→ referencedBy → Action6→ hasVersion → Version7→ validFrom / validTo → Date

For example, when policy documents change, you need to distinguish between decisions based on previous policies and decisions based on new policies.

Therefore, your document extraction pipeline must manage the following:

1# Example structure2Document ID3version4Creation date/revision date5expiration period6ownership team7supporting sentence or paragraph8linked business object

RAG finds document chunks, and KG manages which business object that chunk is associated with.

6. Attaching verification rules and policy engine

For an organization's AI Agent to execute actual tasks, verification is required before execution.

Verification rules can be broadly divided into two types.

SHACL is a standard that verifies that an RDF graph satisfies certain conditions. For example, you can verify the following conditions:

1# Example structure2The onboarding action requires a customer.3A customer must have a contract attached to it.4The contract status must be Signed or Active.5The security review status must be Passed.6The executor must have OnboardingStart permission.7Decisions must be accompanied by supporting documentation.

Conceptually, it goes like this.

1# Example structure2Agent creates candidate actions for execution3↓4Search related subgraphs5↓6SHACL or policy engine validation7↓8Run tool on pass9↓10In case of failure, explain missing conditions to the user

The verification failure message is also important.

The bad message is this:

1# Example structure2Cannot run.

A good message is this:

1# Example structure2Onboarding cannot begin.3reason:41. Customer A’s security screening status is not Passed.52. The current requester does not have OnboardingStart permission.63. The application checklist version has not been confirmed.

These messages prompt the user to take the following actions:

Practical Judgment More important than the quality of your LLM's answers is your ability to explain why you failed when you fail. In organizational automation, “judgment not to execute” is also an important automation outcome.

7. Return Agent execution log to graph

There are aspects that are often missed in AI Agent operations.

Many teams only think of the knowledge graph as “data read by agents.” However, in the organizational AI operating system, the Agent execution results must also be recorded in the graph again.

1# Example structure2Action3→ executedBy → Agent4→ requestedBy → Person5→ executedAt → Timestamp6→ usedTool → Tool7→ basedOn → Evidence8→ produced → Document / Ticket / Decision9→ hasResult → Success / Failed / NeedsApproval

Recording this allows you to:

For example, if an Agent fails to start onboarding, you can graph the reason why.

1# Example structure2Action:StartOnboarding-ExampleA3→ requestedBy → Person:Lee4→ targetCustomer → Customer:A5→ validationStatus → Failed6→ failedBecause → MissingSecurityReview7→ failedBecause → MissingPermission8→ checkedBy → Policy:OnboardingPolicyV3

This log will be very important later.

1# Example structure2Which rules cause a lot of failures?3Which permissions issues do your teams often encounter?4What documents are often used as sources?5Which Agents frequently attempt to call incorrect tools?

Ultimately, the execution log is not just a simple operation log, but becomes learning data that improves the organization's AI operating system.

8. Order of expansion from team to team

It starts with one team's work.

For example, let's say you start with the Customer Success team responsible for customer onboarding.

1# Example structure2Step 1: Automate onboarding within your CSM team3Step 2: Connect with your sales team contract status4Step 3: Connect with your security team review status5Step 4: Create operations team account/associate with deployment status6Step 5: Connect with Finance Billing/Contract Terms7Step 6: Promote to Common Customer/Contract/Policy Model

The important thing when expanding is to expand around common objects.

We don’t connect all the work of all teams from the beginning. Standardize core objects shared across multiple teams.

1# Example structure2Customer3Contract4Product5Project6Person7Team8Policy9Permission10Document11Action12Decision13Evidence

When these objects are repeated across multiple tasks, they can be promoted to organizational standards.

In this order, rather than forcing a “company standard,” concepts that have been repeatedly verified in actual automation become the standard.

Practical Tips Company-wide standards are not established all at once in a conference room, but are reused in multiple tasks, and it is more stable if surviving concepts are promoted to standards.

9. Operating organization and role division

Ontology/KG-based AI automation is difficult to operate with just one team.

The following roles are required:

In small organizations, one person may wear multiple roles. However, the roles themselves must be differentiated.

In particular, it is a good idea to separate the following three responsibilities:

1# Example structure2Responsibility for defining the meaning of work3Responsible for linking data and controlling quality4Responsibility for ensuring that the AI ​​Agent runs safely

During operational meetings, it is recommended to look at the following metrics:

These metrics are more important than just usage. This is because the purpose of an organizational AI operating system is not to use it a lot, but to run it safely and consistently.

10. Failure patterns and avoidance methods

Ontology/KG introduction is a project prone to failure. You need to know the typical failure patterns in advance.

The most dangerous failure is “you create a graph, but the Agent doesn’t actually use it.”

This usually happens for one of the following reasons:

1# Example structure2Could not connect to the Agent tool.3There is no way to cut out the subgraph needed for the question.4Data is not up to date.5Verification rules are not operational.6The business does not trust the graph results.

Therefore, KG construction should be viewed as an agent operation project, not a data project.

11. Practical checklist

The checklist below can be used by your organization to begin actual adoption.

1# Example structure2Step 1: Task Selection3 4[ ] The task to be automated has been narrowed down to one.5[ ] Repetition frequency and expected ROI were confirmed.6[ ] The risk in case of failure is at a manageable level.7[ ] The business owner and domain expert are determined.8 9Step 2: Define the question10 11[ ] Competency questions that the agent must answer are organized into 10 or less.12[ ] The data sources required for each question are identified.13[ ] Success/failure standards are set for each question.14 15Step 3: Minimal ontology16 17[ ] Core classes are defined.18[ ] Core relationships are defined.19[ ] Differences in terminology by team are summarized.20[ ] Can be mapped to existing system fields.21 22Step 4: Connect your data23 24[ ] The necessary sources among CRM/ERP/ticket/document/API are organized.25[ ] There is an entity ID mapping strategy.26[ ] You can track document versions and supporting paragraphs.27[ ] Data freshness requirements are established.28 29Step 5: Verify and Execute30 31[ ] There is authority verification before execution.32[ ] There is policy verification before implementation.33[ ] Missing conditions can be explained to the user.34[ ] High-risk actions are handled human-in-the-loop.35 36Step 6: Operations37 38[ ] Leaves an Agent execution log.39[ ] Records the Action, Evidence, and Decision relationships.40[ ] Analyze failure logs to improve ontology and policies.41[ ] Promote concepts that are reused across multiple teams to standards.

12. Q&A, references, conclusion

Q1. When should I create a transcription ontology?

Rather than creating one from scratch, it is better to promote a concept to an organizational standard when it arises and is reused repeatedly across multiple tasks. For example, if concepts such as Customer, Contract, Policy, Permission, and Evidence are repeated across multiple teams, they are worth standardizing.

Q2. Do I need to move all existing RDBs to Graph DB?

no. You can keep an existing RDB and use a mapping language like R2RML, or you can combine API lookups and graph storage. What is important is not the physical transfer, but the semantic layer and query method.

Q3. Who should manage ontology?

It is realistic for a central platform team to manage structure and quality standards, and for each domain team to manage business concepts and exceptions. A balance of centralization and team autonomy is needed.

Q4. How far should I go during the PoC period?

We recommend that you do not target enterprise scaling in your PoC. It is enough to check one core task, 5 to 10 key questions, a minimum ontology, some data connection, and verification before execution.

Q5. When should I add GraphRAG?

It is recommended to initially start with plain RAGs and object mappings. Review GraphRAG when your question crosses multiple documents and multiple entities, and you need a full structural summary or relationship-based search.

Q6. How should policy engine and SHACL be divided?

SHACL is suitable for verifying the structure and data conditions of RDF graphs. Broader permissions, organizational policies, approval flows, and risk score-based decisions can be separated into separate policy engines.

References and Uncertainty

References

• OpenAI, A practical guide to building agents
• Anthropic, Building Effective AI Agents
• W3C, R2RML: RDB to RDF Mapping Language
• W3C, SPARQL 1.1 Query Language
• W3C, Shapes Constraint Language SHACL
• Microsoft, GraphRAG Documentation

confirmed facts

• R2RML is a W3C standard for mapping relational databases to RDF datasets.
• SPARQL is a W3C standard for querying RDF graphs, and through middleware, you can also query data that looks like RDF.
• SHACL is a W3C standard for verifying that an RDF graph satisfies certain conditions.
• OpenAI and Anthropic describe an approach to agent design that starts from simple, composable structures.

Author's interpretation

• The organizational AI operating system is not an enterprise data integration project, but is closer to an operating system that gradually expands the semantic model of repetitive tasks.
• Rather than setting company-wide standards from scratch, it is more realistic to promote concepts that are reused in multiple tasks.

uncertainty

• Depending on your organization's existing data quality, permissions structure, and system structure, implementation difficulty can vary significantly.
• Financial, healthcare, public and security areas have separate regulatory and auditing requirements and require further review.

finish

In summary, the following sequence is the most realistic way to expand team AI workflow to an organizational AI operating system.

1# Example structure2Workflow Automation3to structure team knowledge4to define common business concepts5to minimal ontology6to work knowledge graph7to validation rules and policy engine8to organization AI operating system

The key is not to build a warrior KG all at once.

In one repetitive task, the question that the AI ​​Agent must answer is defined, the concepts and relationships required for the question are modeled to a minimum, connected to the existing system, verified before execution, and logs added after execution.

If you summarize it in one line, it is like this.

Organizational AI operating system is not a project to create a huge knowledge graph at once, but is a process of expanding semantic models verified in repetitive work to multiple teams.

The main story has been summarized through parts 1 to 3 of this series.

1# Example structure2Part 1: When do you need ontology/KG?3Part 2: What is the role of Ontology, KG, RAG, GraphRAG, and SHACL?4Part 3: Where and how should an organization be introduced?

If you write your next extension, it would be a good idea to cover “Creating a Mini Ontology/KG with New Customer Onboarding Tasks” as a real-world example. Beyond theory, classes, relationships, verification rules, and even Agent execution logs can be shown as examples.

summary card

• One-line summary: Do not create a company-wide KG, but start with a minimum ontology from one core task.
• Recommended for: CTOs, AI TFs, platform teams, and data teams who want to expand AI automation across their organization.
• Not recommended for: Teams that only need a simple document search PoC
• The most important setting: Limiting the scope of the ontology with Competency Questions
• Biggest risk: Data modeling project grows bigger and loses real automation results
• What to do now: Pick three candidate tasks for automation and select only one based on repeatability, risk, and data connectivity.