From AI Demo to Enterprise POC: Access, Logging and Approval

Overview: Restrict → Validate → Log → Test → Reviewable POC controls. The infographic is a learning overview, not a screenshot of an executed result.

Level: Advanced · Hands-on time: approximately 80 minutes, excluding long downloads or account approval · Reading time: 5 minutes

Tools and prerequisites: Completed payment simulation; Python; project code; reviewer worksheet.

Cost: Offline control checks require no API calls. Infrastructure and optional API costs depend on the proposed POC.

A convincing demo answers a few sample questions. An enterprise POC must also show who can access evidence, which proposals are allowed, what a reviewer approved, and what happens when something fails.

You will end with a review package built from the payment simulation: a boundary map, executable rejection tests, a failure drill, an explicit gap list and a go/no-go form. It does not turn a local script into production-grade authorization or an immutable audit system.

Why it matters: stakeholders approve a POC on evidence of what is controlled and what is not. A list of honest gaps is more useful to them than a smooth demo.

1. Build a boundary map

Objective: identify where authority actually lives. In your project, create poc-review.md with this table:

Verify: each real-system gap has a named owner or is explicitly marked unassigned. “The prompt says not to” is not an implementation of access control.

2. Inspect validation before approval

Objective: ensure the reviewer sees a proposal the application has checked. Open payment_rules.py and controls.py. Trace the call sequence: find the selected case, recompute the allowed proposal, compare it, then write the decision.

Run python controls.py and inspect the new rejected event. It includes a timestamp, actor, proposal hash, full proposal, decision and simulation-only effect.

Expected result: the decision is associated with the exact proposal. The SHA-256 hash is a content fingerprint, not encryption and not proof the log was never altered.

3. Run the negative-path checks

Objective: demonstrate rejected behavior rather than merely list controls. Save or inspect test_controls.py:

import copy
import unittest
from payment_rules import CASES, get_case, propose, validate
from controls import write_decision

class ControlsTests(unittest.TestCase):
    def test_reference_and_currency(self):
        self.assertEqual(propose(get_case("PAY-001"))["action"], "propose_assignment")
        for case in CASES[1:]:
            self.assertEqual(propose(case)["action"], "request_review")
    def test_forged_account(self):
        case = get_case("PAY-001")
        proposal = copy.deepcopy(propose(case))
        proposal["account"] = "CA-999"
        with self.assertRaises(ValueError):
            validate(proposal, case)
    def test_unknown_actor(self):
        with self.assertRaises(PermissionError):
            write_decision(propose(get_case("PAY-001")), True, "unknown")
    def test_no_post_action(self):
        proposal = propose(get_case("PAY-001"))
        proposal["action"] = "post"
        with self.assertRaises(ValueError):
            validate(proposal, get_case("PAY-001"))

if __name__ == "__main__":
    unittest.main()

Run:

python -m unittest test_controls.py -v

Expected result: four tests pass, including forged-account and post rejection. Keep the output with the test date and code version. If a prohibited action is accepted, stop and fix the boundary before adding an integration.

4. Add a manual failure drill

Objective: observe what happens when an environmental assumption fails. Work on a disposable copy. Temporarily rename cases.json to cases-backup.json using the file manager, then run python payment_rules.py. Expect a missing-file failure, not a fabricated proposal. Restore the original name immediately afterward.

For the API extension, test an unknown case ID locally. The agent should stop before calling the model. Do not deliberately expose a real key in logs or screenshots to simulate a credential failure.

Verify: every drill has a starting condition, expected behavior, actual behavior and restoration step. A handled failure should be visible to the operator; quietly returning a default assignment would be unsafe.

5. Define production controls as requirements, not claims

Objective: produce a concrete design review. Add these entries to poc-review.md:

Identity provider and reviewer roles:
Evidence sources and access checks:
Approved action list and policy version:
How approval binds to an unchanged proposal:
Expiry and revalidation before execution:
Idempotency key and duplicate-handling rule:
Audit storage, retention and access owner:
API/model usage limit and escalation:
Stop condition and rollback owner:
Release-specific SAP interface evidence:

Fill a field only when you have evidence. Otherwise write “not yet implemented” and assign the work. For a real action, revalidate evidence and authority at execution time; an old approval may no longer match current business state.

Common mistake: calling a local JSON file an enterprise audit trail. This demo file can be edited by anyone with write access. Its value is teaching the event shape and review sequence.

6. Produce a go/no-go review package

Objective: give stakeholders something inspectable. Bundle scope, synthetic fixtures, source code, test output, evaluation results and the gap list. Use this decision form:

Decision: learning demo complete / limited POC approved / no-go
Approved scope:
Explicit exclusions:
Open blocking gaps:
Evidence reviewed:
Accountable reviewer:
Review date and next checkpoint:

Do not prefill “limited POC approved” on someone else’s behalf. This is a reusable form, not a claim that approval has occurred.

Checkpoint: the local learning demo can be complete while enterprise gaps remain open. You have a concrete basis for deciding the next scope, without equating a successful sample run with production readiness.

Final verification checklist

• Boundary table separates implemented behavior from gaps.
• Four negative-path tests pass.
• Failure drill restores the original fixture.
• Review event contains proposal identity and decision.
• No unimplemented production control is claimed.

Completed outcome: Reviewable POC controls. Keep your result and its verification record together.

FAQs

Are these production-ready controls?

No. The local program demonstrates selected checks. The boundary table identifies what a real integration still needs.

Is a hash enough to prove an audit record is authentic?

No. It identifies content; authenticity, access control and tamper evidence require additional design.

Related labs

• SAP FI-CA Payment Clarification Agent: A Step-by-Step POC
• Test Your AI Assistant: Accuracy, Cost and Failure Cases

Sources and research notes

Research checked on 21 October 2026. Official documentation supports the tool behavior and requirements; the fictional fixtures, walkthrough, checks and teaching sequence are original examples. Account access, plans and interface labels can change. See the library validation report for what was executed locally and what still requires a live-service run.

• OWASP agentic security guidance
• NIST AI Risk Management Framework
• OpenAI API data controls
• Python hashlib

Recap

You separated implemented behavior from gaps, ran four negative-path tests, drilled one failure, and produced a decision form that nobody has pre-approved.

Next step

This is the last lab in the series. Complete the review package and make one explicit decision about the next permitted POC scope; the evaluation lab shows how to gather the evidence.

Continue your trail

Previous concept SAP FI-CA Payment Clarification Agent: A Step-by-Step POC Continue along Architecture instead of jumping to a loosely related post.

→

You are here From AI Demo to Enterprise POC: Access, Logging and Approval Reviewable POC controls

→

Recommended next Can Agentic AI Change FI-CA Collections? Why next? Continue along Architecture instead of jumping to a loosely related post.

Knowledge completion

You now have the Architecture context.

Save this guide, continue to the next concept or return to the Knowledge Library with your context intact.

Save Back to Knowledge Explore SAP + AI

Library

← Browse SAP + AI knowledge

Next guide

Can Agentic AI Change FI-CA Collections? →

Knowledge Area

Architecture

7 resources in this area.

Agents 1 › Auditable clarification POC 1 › Cited practice assistant 1 › Controlled proposal 1 › Measured baseline 1 › Read-only tool call 1 › Reviewable POC controls 1 ›

Sachin H. Patil

SAP + AI · Architecture

Practical SAP notes, structured for review, reuse and long-term maintenance.

View profile →