Build an AI Portfolio Project Without Sharing Work Data

How do I choose inputs that are safe to show?

Begin with a recurring task, not a folder of old work. Suppose your job includes turning policy documents into a first-pass list of requirements. You could use public guidance documents, check that their terms allow the planned reuse, and build a small workflow that extracts candidate requirements with links to the relevant passages. If public documents lack a useful edge case, add a clearly labeled example you wrote from scratch. Do not copy internal prompts, customer records, code, metrics, procedures, or document fragments, even after removing names, unless the employer has explicitly approved the data, tools, and publication.

The UK Statistics Authority’s 2025 guidance describes synthetic data as an area with ethical considerations and mitigation questions across its lifecycle. That is a useful caution: ‘synthetic’ describes how data was made, not a blanket finding that it is private. Examples derived from sensitive source records can retain risks, while independently authored examples avoid that particular source-data link. NIST’s AI Risk Management Framework likewise asks its users to define context, privacy requirements, third-party data and rights risks, and the task’s intended scope. It is voluntary organizational guidance, not a portfolio rule or legal approval. The practical choice is public material where it preserves the task’s structure, original examples where it does not, and employer-derived material only with clear authorization.

Sources: AI RMF Core; Ethical considerations relating to the creation and use of synthetic data

What should the AI part prove?

Give the AI one bounded job and test that job against examples whose expected result you have checked yourself. In the policy-document example, the system might draft candidate obligations; your project can preserve the source passage for each item, flag items with no supporting passage, and show your corrections. Keep a small test set that includes straightforward cases and cases likely to expose omissions or unsupported additions. Report what happened in that set and show a failure, if one occurs. Do not convert a handful of examples into a broad accuracy claim or imply that a successful demonstration proves production reliability.

NIST’s framework supports this emphasis on inspectability: it calls for documenting the specific task and method, knowledge limits, human oversight, test sets, metrics, and performance assessment. For a portfolio project, translate that into a short record of the question you tested, what counted as an acceptable answer, what the system returned, and what you changed. The human contribution should be visible in decisions such as rejecting an unsupported extraction or deciding that an ambiguous passage needs context. The value of this demonstration is what a viewer can inspect about your task understanding and verification, not a claimed productivity gain or a claim that employers have adopted the same workflow.

Sources: AI RMF Core

How do I make the project easy to inspect?

A useful project page lets a reader orient themselves before exploring code or a demo. GitHub’s repository documentation says a README can explain what a project does, why it is useful, and how to get started; its profile guidance also recommends an overview, example or demo, and testing instructions for showcased projects. Apply that advice with a compact sequence: task and intended user; input provenance and reuse notes; the AI-assisted step; a few checked examples; observed errors and human review; known limits; and one next improvement. Link to the test cases and make the project runnable when your skills and time allow. A clean demo is welcome, but it cannot substitute for evidence about what was tested.

A public AI portfolio repository opened during research illustrates one presentation choice: it labels evidence as real local implementation, public-source subset, synthetic data, simulation, or generated artifact, and describes boundaries alongside results. That is an example of transparent labeling, not evidence that this format improves hiring outcomes. For your own first project, a spreadsheet of expected answers and a short written review may be enough; a custom application is optional. Set an honest boundary: this small exercise shows how you approached a defined task under stated conditions, not how you would perform on confidential production data.

Verdict: choose the smallest slice that preserves the judgment in your work. First write down one recurring task and the decision it supports. Next find permitted public inputs or create independent examples, then define checks before building the AI step. Finally document the results, failures, limits, and your edits, and review the repository for secrets and rights issues before sharing. If the project fits your current role or a nearby move, improve that work sample before committing scarce time or money to a broad course. If you still need to identify which tasks matter most in your role, the free checker can surface task-level change-pressure signals; those signals are not a probability of job loss.

Sources: About the repository README file; AI Portfolio README: evaluated projects and evidence labels