Outcome
~75% faster
credit-risk workflow analysis
Analyst-assistive workflow combining public-company risk signals with internal context into structured recommendations.
00 / overview Belgrade, Serbia · works internationally
Internal AI systems that hold up in real use
Many internal AI systems can work in a demo. I build and harden the ones that need to survive real users, real operators, and real operating costs, with evaluation, access boundaries, cost visibility, and handoff designed in from the start.
Operating brief
- Focus
- Analyst-support, knowledge-access, and internal workflow systems where trust, adoption, and operating constraints matter.
- Position
- Project-based build and hardening, with advisory tied to real delivery decisions.
- Delivery posture
- Evaluation, cost visibility, human review, access boundaries, and handoff are treated as part of the system.
Adoption
300+ users
self-hosted internal assistant
300+ users out of roughly 1,500 eligible, with 85%+ positive explicit feedback after launch.
Scale
50+ workflows assessed
from opportunity framing to rollout decisions
AI work across finance, operations, logistics, and adjacent teams, separating useful systems from interesting ideas across assessment, PoCs, and first scaled rollout.
01 / selected work
Selected work
Concrete delivery choices, system shape, and outcomes that mattered.
Delta Holding
Case 01Credit-risk decision-support workflow
A credit-risk decision-support workflow built in-house at Delta Holding, combining public-company risk signals with internal operating context into structured, analyst-ready recommendations.
- Context
- B2B credit-risk analysis and limit-setting workflow inside a multi-entity enterprise finance function.
- Outcome
- Observed workflow outcomes included ~75% faster analysis, 4.4/5 analyst-rated quality, and 90%+ recommendation acceptance.
PythonLLM APIsWorkflow designStructured decision support
Delta Holding
Case 02Self-hosted internal knowledge assistant
A self-hosted internal knowledge assistant built in-house at Delta Holding, with Azure AD-scoped access, operator/admin surfaces, feedback loops, and usage and cost observability built in from the first version.
- Context
- Internal enterprise knowledge-access system serving multiple business units, with requirements around access control, quality governance, and operational visibility.
- Adoption and feedback signal
- Deployed across roughly 1,500 eligible users, with 300+ actual users and 85%+ positive explicit feedback on thumbs-up/down responses.
FlaskDockerPostgreSQLpgvectorLangChainAzure AD SSO
02 / context
About Stefan
Enterprise AI delivery shaped by finance, industrial, and earlier decision-support environments.
I currently work in an enterprise and industrial environment and previously spent four years at Delta Holding, progressing from AI Specialist to AI Innovation Lead while helping move internal AI from early opportunity framing to first scaled rollout across multiple business units.
Before the current AI cycle, I worked on decision-support systems in operational agriculture and BI settings: predictive plant-protection and irrigation workflows, IoT-backed field data, ETL, KPI reporting, and teams that only adopted tools if they helped the real operating work. That background is why I treat system shape, adoption path, and ownership as first-order design constraints, not implementation cleanup.
Availability
Available for selective project work.
Current work
Applied AI for internal industrial workflows and data-intensive engineering contexts. Public description is intentionally limited to workflow and problem shape.
Delivery environments
Delta Holding work across credit workflows, internal assistants, and AI delivery programs, plus earlier decision-support systems in operational environments.
Working principle
Workflow fit, reviewability, and handoff quality matter as much as model output. A system has to earn continued use; it does not get it by default.
Operating model
Scope → Build → Harden → HandoffA compact operating artifact: define the workflow, ship the first version, tighten the edges, and leave the team something it can run.
01 / scope
Align on workflow and constraints
Define the users, ownership, timing, and what useful needs to mean in practice.
02 / build
Ship a first version
Use decisions that support real use, feedback, and reliable deployment.
03 / harden
Tighten the failure modes
Make evaluation, reviewability, and operator visibility part of the system.
04 / handoff
Leave something operable
The team should be able to run, review, and extend the work without mythology.
03 / services
How I help
Project-based build first, with hardening and advisory work where they improve reliability, reviewability, and handoff.
Build is the main entry point. The service page goes deeper on workflow starting points, engagement flow, and where hardening or advisory work help a system survive real operating conditions.
Teams usually reach out when they need to decide whether an AI workflow is worth building, harden a prototype that only works in demo conditions, prepare an internal assistant for real use, or build decision-support around an analyst workflow.
Primary mode
Build
Project-based delivery of internal AI systems for enterprise and mid-market teams with a concrete workflow to improve and a real operating context to support.
- Internal assistants, knowledge-access systems, and analyst-support workflows
- Evaluation-gated first versions with review and access decisions made explicit
- Ownership from scoped workflow to shipped implementation and handoff
Secondary mode
Hardening
Take a prototype or pilot already in motion and make it more reliable, reviewable, observable, and ready for real use.
- Evaluation, failure-mode, and review-path hardening
- Access model, observability, usage signals, and cost visibility
- Prototype-to-production cleanup and handoff readiness
Secondary mode
Advisory
Scoped advisory work that sharpens system shape, delivery path, and implementation risk before or alongside build work.
- Architecture and workflow review
- Use-case, ownership, and delivery scoping
- Implementation risk and handoff planning
04 / public proof
Working style
A public proof point for the working style behind the delivery.
The Agentic Development Playbook is a public artifact showing how I keep AI implementation scoped, reviewable, and evaluation-gated once work becomes repo-level and real delivery starts.
Public artifact, not a private claims page: scoped tasks, verification before commit, repo files as the source of truth, and a light PoC/evaluation path when early work still needs decision-grade evidence. That discipline is what makes delivered work auditable, operable, and easier for your team to extend after the engagement ends.
View the Playbook → 05 / fit
Fit guidance
The strongest work starts with a clear operating problem, real users, and a reason the system needs to hold up once it's live.
Good fit
- Teams with a concrete internal workflow, real users, and a reason the system needs to earn continued use once it is deployed.
- Decision-support, knowledge-access, and internal tooling systems that need disciplined evaluation and delivery.
- Project-based build, hardening, or advisory work with clear ownership and real business pull.
Usually too early or not the right shape
- Pure idea-stage exploration with no real workflow owner or adoption path.
- Generic “AI transformation” requests without a defined problem to solve.
- Chatbot or demo-first work where operational quality and adoption are not the goal.
Workflow review
If the workflow is concrete enough to describe, I can usually tell quickly whether a build or advisory conversation makes sense.
I take on project-based build, hardening, and advisory work for internal AI systems. A short description of the workflow, the current stage, and the key constraints is enough to tell whether the engagement makes sense.