Partner Program​

• IP retention – when code or business logic is sent to a cloud LLM, who owns what comes back? Does it train the vendor’s model?
• Data residency & compliance -HIPAA, PCI-DSS, GDPR, and FedRAMP often prohibit sensitive data leaving defined boundaries. Sending PII to a US cloud LLM creates instant compliance exposure.
• Shadow AI -employees are already using ChatGPT and Claude without IT visibility, with sensitive IP leaving the building with no audit trail.
• Model selection risk – developers individually choosing which model to use, with no central oversight, creates inconsistent security posture and cost blowout.
• Auditability – in a regulated environment, ‘the AI said so’ is not sufficient. Without a per-call record of which model saw which data under which policy, enterprises cannot demonstrate compliance.

• IP & data leakage – the AI Governance policy engine classifies every field automatically via the Zetaris semantic layer, detecting PII without manual tagging, and can redact sensitive data before it reaches a cloud model.
• Data residency – the private on-prem Llama-based LLM means sensitive workloads never leave the building; the same binary runs air-gapped.
• Shadow AI -admins define which model handles which classification of request; developers and users no longer choose the model – policy does.
• Auditability -every model call generates an audit record (policy applied, model used, data classification, prompt hash), CSV-exportable, with a Test Console to validate before go-live.
• Seven ready policy templates – HIPAA/PCI, Air-Gapped, Sovereign, Balanced, and more — give compliance teams a starting point rather than a blank page.

Absolutely-this is arguably PIES’s strongest commercial narrative. PIES doesn’t compete with Claude and OpenAI — it harnesses them. An enterprise going all-in on Claude still needs: 

• A way to govern which data Claude sees
• A way to audit every Claude call for compliance
• A private fallback for data that cannot reach any cloud model
• A way to build and deploy applications that use Claude, not just chat with it
• MCP-native apps so their Claude-based agents can actually do things

PIES wraps Claude in the control layer that enterprise compliance, security, and risk teams require before allowing Claude to touch production data – de-risking the Claude relationship for the CISO while accelerating it for engineering. 

Yes. The three-tier AI engine gives enterprises genuine optionality: 

• Anthropic Claude – frontier reasoning, up to 1M context window, for the hardest tasks.
• OpenAI / Azure OpenAI – cost and speed-optimised for high-volume generation workloads.
• PIES Private LLM – Llama-based, running on the customer’s own hardware, with LoRA fine-tuning capability. No per-token billing, no data leaving the building, and a model that gets progressively better at your specific work.

The LoRA fine-tuning point is significant: an enterprise can continuously train the private model on their accepted code outputs, domain terminology, and workflow patterns -building a proprietary AI asset over time. 

Phase 1 — Application Development & Cost Reduction 

AI-assisted generation compresses multi-quarter development backlogs into weeks. Code ownership eliminates vendor lock-in tax. For large enterprises running dozens of internal apps, the build-and-run cost reduction alone is a compelling business case. 

 Phase 2 — Agentic Workflow Implementation 

Every deployed PIES app is MCP-native, making the enterprise’s application portfolio immediately accessible to AI agents. Workflows requiring human orchestration — approval chains, data aggregation, compliance checks — can be handed to governed agents. The same headcount achieves significantly more throughput. 

 Phase 3 — Autonomous AI Operations 

As the private LLM is continuously fine-tuned on accepted outputs, it becomes an increasingly capable autonomous operator. Agents trained on your workflows begin handling end-to-end processes without human initiation. This is the compounding moat — and the valuation story. 

1. Alignment & Safety -AI systems pursuing subtly wrong objectives create product liability exposure at scale. Enterprises must build elaborate human-in-the-loop safeguards that erode the efficiency gains AI was supposed to deliver.
2. Concentration of Power-AI development has consolidated around a handful of frontier labs and cloud providers, creating structural barriers to entry higher than any in the history of computing.
3. Misinformation – Generative AI has industrialised synthetic content creation. The cost of convincing fakes has dropped to zero, corrupting evidentiary standards and increasing friction in every commercial interaction.
4. Labour Disruption- This wave targets cognitive, credentialed work — writing, coding, legal research, financial modelling. Entry-level knowledge work is being hollowed out faster than new career ladders are being built.
5. Governance & Accountability – AI governance is a patchwork of inconsistent national regulations. Liability for AI-caused harm remains unresolved in most jurisdictions, paralysing adoption in healthcare, legal, and finance.

 The thread connecting all five commercially is trust erosion. Companies that solve these issues-rather than navigate around them -will have the most durable commercial positions. 

Every prompt entered into a public LLM externalises organisational knowledge. Because public AI providers often have unclear data retention and training policies, businesses risk losing control over proprietary information while gaining little visibility into how that data is used. 

 Public LLM risks: IP leakage via prompts, unclear data retention policies, compliance exposure, shadow AI adoption, and no per-call audit trail. Public AI systems are externally controlled platforms with their own commercial incentives. 

 Private LLM advantage: deployed behind the organisation’s firewall — full AI capabilities while keeping data, knowledge, and competitive advantage secure and under organisational control. AI sovereignty rather than AI dependency. 

 The rapid adoption of public LLMs mirrors the shadow IT problems of previous decades — but at a much faster scale, with much higher-value IP at stake.  

AI is the broad field of building systems that mimic human intelligence. Machine learning (ML) is a subset where models learn from data rather than explicit rules. Deep learning is a subset of ML that uses multi-layer neural networks — it powers most modern language and vision models. 

An LLM is a neural network trained on vast amounts of text to predict the next token in a sequence. Through this process it develops internal representations of language, facts, and reasoning patterns. At inference time, it generates text autoregressively — one token at a time — based on the context (prompt) provided. 

Supervised learning trains on labelled input-output pairs. Unsupervised learning finds structure in unlabelled data (e.g. clustering). Reinforcement learning trains an agent to maximise reward through trial and error in an environment. Most LLMs are pre-trained with self-supervised learning, then fine-tuned with reinforcement learning from human feedback (RLHF). 

An embedding is a dense numeric vector that represents data (text, images, etc.) in a high-dimensional space, where semantically similar items cluster together. They are the foundation of semantic search, retrieval-augmented generation (RAG), and recommendation systems. 

The transformer is the neural network architecture underpinning most modern LLMs. Its key innovation is self-attention — each token can attend to every other token in the context window simultaneously, capturing long-range dependencies far more effectively than older RNNs or LSTMs. 

APIs are the connective tissue of AI development — they let your application communicate with AI models and services without building or hosting those models yourself. 

• Access without infrastructure – call a frontier model like Claude or GPT-4 with a single HTTP request. No GPU cluster required.
• Standardised communication -APIs define a fixed contract (inputs: model, messages, parameters; outputs: response, token counts) so your code stays stable as models improve.
• Tool & function calling – the model can request your app to run a function and incorporate the result, enabling full agent loops.
• Composability – chain embeddings, completions, image, and speech APIs together, each doing one job well.
• Auth, rate limits & safety – API keys authenticate your app, rate limits prevent abuse, and the provider’s safety layer filters harmful outputs.
• Scalability – send 1 request or 10,000 concurrently. You pay per token used, not idle capacity.

Consider: task type (coding, reasoning, vision), context window size, latency requirements, cost per token, data privacy (cloud vs self-hosted), and model licensing. Open-source models (Llama, Mistral, Qwen) are preferable when data must stay on-premise. Benchmark on your specific workload leaderboard scores rarely translate directly. 

Tokens are the units models process roughly 4 characters or three-quarters of a word in English. API pricing is per-token (input + output). Longer prompts consume more tokens and increase latency. Always profile token usage in production; use streaming to improve perceived latency for long outputs.

The context window is the maximum number of tokens a model can ‘see’ at once (prompt + response). Larger windows let you include more documents or conversation history, but also increase cost and can dilute attention on key information (‘lost in the middle’ problem). Chunk and retrieve rather than stuffing everything in.

Fine-tuning continues training a pre-trained model on your own dataset to adapt its style, format, or domain knowledge. Use it when prompt engineering alone can’t achieve the required output format consistency, or when you need to bake in proprietary domain knowledge efficiently. It requires quality labelled data and is more expensive than prompting.

Zero-shot: no examples in the prompt, relying on the model’s pre-trained knowledge. Few-shot: include 2-10 input/output examples in the prompt to guide format/style. Fine-tuning: actually update model weights on hundreds to thousands of examples. Start with zero-shot, then few-shot, then fine-tuning in that order; each step is more costly.

Prompt engineering is the craft of structuring the input to an LLM to reliably produce the output you need. It covers instruction clarity, few-shot examples, persona setting, output format specification, chain-of-thought elicitation, and constraint setting. It is iterative — treat prompts like code and version-control them.

CoT prompting asks the model to reason step-by-step before giving its final answer. Adding ‘Let’s think step by step’ or providing worked-example reasoning in few-shot demonstrations significantly improves performance on multi-step maths, logic, and coding tasks.

RAG combines a retrieval system (vector database + embeddings) with an LLM. At query time, relevant documents are fetched and injected into the prompt, grounding the model’s response in up-to-date or proprietary data without retraining. It is the dominant pattern for knowledge-intensive applications.

Hallucinations stem from the model generating plausible-sounding but unfounded text. Mitigations: use RAG to ground responses in retrieved sources, instruct the model to say ‘I don’t know’, request citations, lower temperature, add consistency checks, and implement human-in-the-loop review for high-stakes outputs.

The system prompt is an instruction block passed before the conversation that sets the model’s persona, rules, output format, and constraints. Use it to define the model’s role, specify response format (JSON, markdown), set tone, list hard constraints, and provide background context that applies to every turn.

A chatbot responds to a single user turn. An agent is an LLM that takes multi-step actions — it can call tools (web search, code execution, APIs), observe results, and plan its next step in a loop until a goal is achieved. Agents introduce autonomy, which requires robust error handling, guardrails, and human oversight checkpoints.

Function calling lets an LLM emit structured JSON to invoke developer-defined functions (e.g. get_weather, run_query) rather than answering in plain text. The developer executes the function, returns the result, and the model incorporates it into its response. It is the primary mechanism for giving LLMs access to live data and side-effecting actions.

MCP is an open standard introduced by Anthropic in 2024 that defines a universal interface for connecting AI models to external tools, data sources, and services. Think of it as USB-C for AI integrations instead of every app building custom connectors for every AI model, any MCP-compatible client (Claude, Cursor, VS Code, etc.) can connect to any MCP-compatible server (GitHub, Slack, databases, local files, APIs) using the same protocol.

A vector database stores and indexes embeddings for fast approximate-nearest-neighbour (ANN) search. Popular options: Pinecone (managed, easy), Weaviate (open-source, feature-rich), Qdrant (Rust-based, fast), pgvector (PostgreSQL extension — best if you’re already on Postgres). For prototyping, even FAISS in memory works.

Frameworks like LangChain, LlamaIndex, and LangGraph provide pre-built abstractions for chains, agents, RAG pipelines, and memory. They accelerate prototyping but add abstraction overhead. For production, many teams replace framework code with direct API calls and custom logic for better observability and control.

Multiple specialised AI agents collaborate to complete complex tasks — one plans, one researches, one codes, one reviews. Frameworks like AutoGen and CrewAI implement this pattern. Benefits: parallelism, separation of concerns, specialisation. Challenges: inter-agent communication overhead, error propagation, and cost.

Use a combination of: automated metrics (BLEU/ROUGE for summarisation, pass@k for code), LLM-as-judge (a second model scores outputs against a rubric), human preference rating, and task-specific golden-set tests. Track all three over time — no single metric is sufficient. Log all production inputs/outputs for offline analysis.

Implement exponential backoff with jitter for retries, use a queue to smooth traffic spikes, cache identical requests where appropriate, and consider multiple provider fallbacks (e.g. primary: Claude, fallback: OpenAI). Monitor API latency and error rates with alerting.

Profile token usage per request, cache embeddings and repeated completions, use smaller/cheaper models for simpler subtasks, apply prompt compression techniques, set hard max_tokens limits, and implement usage quotas per user/team. A cost dashboard with per-feature breakdowns is essential.

Treat prompts as code: store them in version control, use a prompt management tool (LangSmith, PromptLayer, Langfuse) to track versions and run A/B tests, add tests that run on every prompt change, and document the intent and expected behaviour of each prompt.

You need: LLM-specific tracing (spans per model call with token counts, latency, model version) via Langfuse, LangSmith, or Arize Phoenix; standard infra monitoring (CPU/GPU, memory, API error rates); cost dashboards; and a way to log and search production prompts and completions for debugging. OpenTelemetry is increasingly standard for the trace layer.

Use the model provider’s streaming API (Server-Sent Events). On the backend, open an SSE or WebSocket connection and forward tokens as they arrive. On the frontend, consume the stream and append tokens to the UI progressively. This dramatically reduces perceived latency — users see the first word in ~500ms instead of waiting 10 seconds.

Prompt injection is when malicious user input manipulates the model into ignoring its system prompt instructions. Defences: clearly delimit untrusted input in the prompt (XML tags, explicit labelling), instruct the model to treat user content as data not commands, validate outputs, and use least-privilege tool access.

Audit training data and outputs for demographic bias, test across diverse user groups, use bias-detection tools (Fairlearn, AI Fairness 360), document model cards with known limitations, implement human review for high-impact decisions, and establish a feedback mechanism for affected users to report harm.

The EU AI Act (risk-tiered regulation, high-risk systems require conformity assessments), GDPR/Privacy laws for any personal data used in training or inference, US sector-specific guidance (FTC, FDA for medical AI), and Australia’s voluntary AI Ethics Framework. Requirements vary by jurisdiction and use case — legal review is essential for high-risk deployments.

For application developers: implement output filtering and content moderation, add human-in-the-loop for irreversible or high-stakes actions, apply least-privilege principles to agent tool access, log all decisions for auditability, define clear escalation paths, and stay updated on your model provider’s safety guidelines and model cards.