Inspiration
Enterprise systems like SAP manage some of the most critical workflows in an organization — finance transactions, procurement orders, HR records, and operational processes. As AI tools become more capable, organizations want to integrate them into these workflows to improve efficiency and decision-making.
However, unrestricted AI access to sensitive enterprise data creates real risks. A model generating an HR summary or sending a financial document without oversight could introduce compliance violations, privacy issues, or operational errors.
We were inspired by a simple question:
How can we safely embed AI into enterprise workflows without sacrificing control, visibility, or trust?
Our goal became designing a system where AI is not just powerful, but governed — where every request is observable, policy-aware, and human-supervised when necessary.
That vision led to the creation of SAP Tracker, a context-aware AI workflow guardrail system.
What it does
Our system enables safe, context-aware AI assistance inside SAP workflows. Instead of allowing unrestricted model access to enterprise data, every AI request is routed through a controlled gateway that evaluates:
the SAP business domain involved the sensitivity of the data the action being requested whether human approval is required
This allows organizations to safely integrate AI into high-stakes workflows across finance, procurement, sales, operations, and HR.
The result is an architecture where AI becomes a governed component of the workflow rather than an unmonitored automation layer.
Why this matters
Enterprise systems like SAP manage some of the most sensitive operational data in an organization. A financial transaction, HR record, or supplier order may involve regulatory, privacy, and operational risk.
While AI can dramatically improve productivity—by summarizing records, drafting communications, or automating workflows—it must operate within strict guardrails.
We designed this system to:
enable AI-assisted business workflows safely prevent unauthorized or risky automation maintain human oversight for critical actions create a full audit trail of AI activity support enterprise-grade governance and compliance
In short, we focused on trust, observability, and control, not just automation.
How we built it
Our architecture separates workflow orchestration, policy enforcement, model routing, and user interaction into clearly defined layers. This separation makes the system easier to scale, audit, and secure.
Core architectural principles Event-driven workflows Context-aware routing Sensitivity-based guardrails Human-in-the-loop approval Full auditability
Every AI action follows the same lifecycle:
A user triggers an action The system records the request The request is classified Guardrails are applied The model generates output A human reviews if required The workflow completes safely Architecture Supabase — System of record
Supabase serves as the primary persistence layer for both business data and AI workflow state.
It stores:
SAP-linked business records workflow state transitions AI action requests generated outputs UI-facing status updates
We chose Supabase because it provides:
structured relational storage real-time subscriptions for UI updates simple integration with edge functions predictable operational behavior
This allowed us to build a reliable event-driven workflow without introducing unnecessary infrastructure complexity.
Edge functions — Workflow triggers
Edge functions detect changes in workflow state and initiate downstream processing.
They are intentionally lightweight and do not enforce policy logic.
Their responsibilities include:
listening for qualifying table updates triggering workflow execution forwarding requests to the internal gateway
This keeps orchestration reactive while ensuring guardrails remain centralized.
Internal API gateway — Policy and guardrail engine
The internal gateway is the core decision-making component of the system.
It evaluates every request before any model is called.
The gateway determines:
the business domain of the request the sensitivity level of the record the type of action being performed whether the action requires human review which model route is permitted
This layer ensures AI operates under defined enterprise policies rather than direct user input.
Lava — Model routing layer
Lava serves as the external model gateway.
Instead of connecting directly to model providers, requests pass through Lava as a deterministic routing layer.
We selected this approach to enable:
provider abstraction consistent request routing centralized model governance controlled integration with approved AI providers
This design keeps model infrastructure separate from business logic and policy enforcement.
UI — Human control surface
The user interface is both the entry point and the approval mechanism for AI-driven workflows.
It allows users to:
trigger business actions monitor workflow status review generated outputs approve or reject final actions
This ensures critical operations remain human-supervised, even when AI is involved.
Data model
We modeled records across major SAP business domains using a shared structure that includes workflow state and sensitivity classification.
This allows the system to apply consistent guardrails across different operational areas.
Finance finance_records ( id uuid primary key, sap_record_id text, amount numeric, currency_code text, status text, sensitivity_class text, created_at timestamptz, updated_at timestamptz ) Procurement procurement_records ( id uuid primary key, sap_record_id text, supplier_id text, quantity numeric, status text, sensitivity_class text, created_at timestamptz, updated_at timestamptz ) Sales sales_records ( id uuid primary key, sap_record_id text, customer_id text, net_amount numeric, status text, sensitivity_class text, created_at timestamptz, updated_at timestamptz ) HR hr_records ( id uuid primary key, sap_record_id text, employee_id text, employment_status text, status text, sensitivity_class text, created_at timestamptz, updated_at timestamptz ) Operations operations_records ( id uuid primary key, sap_record_id text, material_id text, status text, sensitivity_class text, created_at timestamptz, updated_at timestamptz ) Workflow status pending synced error Sensitivity levels low high UI action model
To make AI actions observable and auditable, user-triggered operations are stored as structured workflow requests.
action_requests ( id uuid primary key, source_record_id uuid, action_type text, status text, created_at timestamptz, updated_at timestamptz ) action_type text check ( action_type in ( 'summarize', 'draft', 'send', 'review' ) )
This design allows asynchronous processing while preserving visibility into workflow state.
Example workflow: sending an order
A typical sales workflow proceeds as follows:
A user opens an order page The user clicks Send order The frontend writes a new action request to Supabase An edge function detects the request The internal gateway classifies the request as a sales-domain action The system evaluates sensitivity and routing rules The request is forwarded through Lava to the approved model path The generated output is stored in Supabase The UI updates automatically The user reviews and approves the final action
This workflow ensures AI operates within a controlled execution path rather than a direct automation pipeline.
Why we chose this architecture
We intentionally separated responsibilities across layers to improve safety, scalability, and maintainability.
Separation of concerns
Supabase Handles persistence and workflow state
Edge functions Handle event-driven triggers
Internal gateway Handles guardrails and policy decisions
Lava Handles model routing
UI Handles user interaction and approval
This modular structure makes the system easier to reason about, audit, and extend.
Challenges we ran into
One of the biggest challenges was balancing automation with safety.
AI systems can execute tasks quickly, but enterprise workflows require:
predictable behavior clear audit trails controlled access to sensitive data human oversight for high-risk actions
We addressed this by designing a centralized guardrail layer that evaluates context before any model invocation.
Another challenge was maintaining responsiveness while preserving control. By using event-driven triggers and asynchronous workflows, we ensured the system remained fast without sacrificing governance.
What makes this project strong
This system demonstrates how AI can be integrated into enterprise workflows responsibly.
Key strengths include:
Context-aware routing Sensitivity-based guardrails Human-in-the-loop approval Full workflow observability Provider-agnostic model routing Enterprise-ready architecture
Rather than treating AI as a standalone feature, we designed it as a governed component of operational workflows.
Future improvements
We plan to extend the system with:
role-based access control policies regulatory compliance enforcement risk scoring for workflow actions automated audit logging dashboards multi-model fallback routing domain-specific guardrail policies
These enhancements would further strengthen enterprise readiness and governance.
Key takeaway
Our project is not just about adding AI to SAP workflows.
It is about making AI safe, observable, and trustworthy in environments where mistakes carry real consequences.
By routing every request through a context-aware guardrail system with human oversight, we enable organizations to adopt AI confidently while maintaining control over sensitive operations.
Log in or sign up for Devpost to join the conversation.