Unit 4: Practical Prompt Design with Vertex AI

CSG202 — Generative Ai Fundamentals 7 min read

Responsible AI is the discipline of designing, building, and deploying machine learning systems so that they are fair, accountable, safe, and aligned with human values. This unit treats it not as an ethics afterthought but as an engineering and business requirement that shapes how models — including generative systems on platforms like Vertex AI — are prompted, evaluated, and governed.

Working definition: the practice of developing AI that is socially beneficial, avoids unfair bias, is built and tested for safety, is accountable to people, incorporates privacy, upholds scientific excellence, and is limited to responsible uses.
Core assumption: technology is not neutral; design choices encode values, so trade-offs must be made deliberately rather than by default.
Governing principle: responsibility is a lifecycle property — it spans problem framing, data, training, evaluation, deployment, and monitoring, not a single sign-off gate.
Convention used throughout: every risk is treated as spottable early, and every principle must map to a concrete process, owner, or metric to be real.

II. The Business Case for Responsible AI

Why responsibility pays rather than costs.

Responsible AI is defended on commercial grounds, not only moral ones: it protects revenue, trust, and the licence to operate.

A. Explain the business case for responsible AI

The argument is that irresponsible AI creates concrete, measurable losses while responsible practice preserves durable value.

Trust as an asset: customers, regulators, and partners extend business only to systems they believe are safe; a single publicised failure (biased hiring model, hallucinated legal citation) erodes brand equity that took years to build.
Risk and cost avoidance: rework, recalls, litigation, and regulatory fines are far more expensive than up-front review. Example: retraining and re-auditing a deployed model after a discrimination complaint costs multiples of designing fairness checks into the original pipeline.
Regulatory readiness: frameworks such as the EU AI Act and sector rules impose obligations on high-risk systems; organisations that already document data, testing, and oversight absorb new law cheaply.
Product quality and adoption: safety, robustness, and reduced bias improve accuracy for underserved segments, widening the addressable market rather than shrinking it.
Talent and investment: engineers and investors increasingly select organisations whose practices they can defend publicly.
Sustained value over one-off gains:
- Short-term temptation: ship fast, defer safety.
- Long-term reality: unmanaged harm compounds into withdrawal of products and loss of the market position that motivated the launch.

III. Ethical Considerations and Issue Spotting

Naming harms before they ship.

The central skill is recognising where an AI system can cause harm, using structured prompts rather than intuition.

A. Identify ethical considerations with AI using issue spotting best practices

Issue spotting is a disciplined scan of a proposed system against a checklist of recurring harm categories, done early and repeatedly.

Fairness and bias: ask whether training data under-represents groups or encodes historical prejudice. Anchor: a résumé screener trained on past hires can learn to down-rank candidates from groups historically excluded.
Transparency and explainability: ask whether affected people can understand or contest a decision — critical for credit, healthcare, and hiring outputs.
Privacy: ask what personal data enters training or prompts, whether consent exists, and whether the model can leak memorised data.
Safety and security: probe for adversarial inputs, prompt injection, and misuse; a generative assistant may be coaxed into producing harmful instructions.
Accountability: ask who is answerable when the system errs and whether a human can intervene or override.
Best-practice method for spotting:
- Ask early: raise questions at design, when changes are cheap, not after launch.
- Ask broadly: convene diverse reviewers so blind spots differ; include domain, legal, and affected-community perspectives.
- Ask concretely: frame each risk against a specific user, use case, and worst-case scenario rather than in the abstract.
- Ask repeatedly: re-spot after data, model, or context changes.

IV. Google's AI Principles in Practice

From published values to operating discipline.

Google published a set of AI Principles in 2018 and built internal machinery to enforce them, offering a documented example of translating stated values into practice.

A. Describe how Google developed and put their AI Principles into practice

The principles emerged from internal debate and were paired with review structures so they governed real product decisions.

Origin and content: the 2018 principles commit AI to be socially beneficial, avoid unfair bias, be built and tested for safety, be accountable to people, incorporate privacy by design, uphold scientific excellence, and be made available for uses consistent with these aims.
Explicit prohibitions: stated limits on pursuing technologies that cause overall harm, weapons whose principal purpose is injury, surveillance violating international norms, and uses contravening widely accepted law and human rights — the principles say what not to build.
Review infrastructure: dedicated review bodies and a formal intake process assess proposals against the principles, escalating hard cases to senior committees rather than leaving them to individual teams.
Tooling and research: investment in fairness testing, interpretability, and safety tooling (bias metrics, model documentation, dataset analysis) so principles are enforced with instruments, not memos.
From statement to gate:
1. Aspirational text: principles alone set direction but decide nothing.
2. Enforced process: binding review, named owners, and the power to halt a launch turn text into practice.

B. Leverage their lessons learned

Google frames its experience as reusable lessons for other organisations, not as a claim of having solved the problem.

Operationalisation is the hard part: the difficulty is not agreeing on values but building repeatable processes that apply them consistently under deadline pressure.
Trade-offs are unavoidable: fairness, accuracy, privacy, and explainability often pull against each other; decisions must be made and documented, not pretended away.
Context determines acceptability: the same model may be fine in one use and harmful in another, so review must consider deployment context, not the model in isolation.
Diverse review improves outcomes: including varied disciplines and backgrounds surfaces harms a homogeneous team misses.
Iterate and expect imperfection: principles and processes are revised as technology and understanding evolve; responsible AI is continuous, not a finished state.

V. A Framework for Operationalizing Responsible AI

Turning intent into an organisational routine.

Operationalising means embedding responsible practice into structures, roles, and workflows so it happens by default rather than by heroics.

A. Adopt a framework for how to operationalize responsible AI in your organization

The framework converts principles into governance, people, and process that recur across every project.

Define principles and scope: write down what your organisation will and will not build, tailored to your industry, so teams share a concrete standard to test against.
Establish governance and ownership: name accountable owners and a review body with real authority to approve, modify, or block deployments; ambiguity about who decides is itself a failure mode.
Embed reviews across the lifecycle: insert checkpoints at problem framing, data collection, model evaluation, pre-launch, and post-launch monitoring, so issue spotting recurs rather than happening once.
- Pre-launch: test for bias, safety, and privacy against defined metrics before release.
- Post-launch: monitor live behaviour, collect feedback, and re-review when data or usage drifts.
Provide tools and training: supply fairness metrics, model and dataset documentation, and explainability methods, and train practitioners to use them, so responsibility is not left to individual conscience.
Build a culture of raising concerns: create safe, low-friction channels for employees to flag risks early and reward doing so, since the earliest signals usually come from the people closest to the work.
Document and iterate: record decisions, trade-offs, and rationales to support accountability and auditing, and revise the framework as technology, regulation, and evidence change.
Worked application — deploying a Vertex AI generative support assistant:
1. Frame and spot: identify risks — hallucinated advice, leaked customer data, biased tone toward some users.
2. Design controls: ground prompts in verified knowledge, filter sensitive data from context, add safety instructions and output checks.
3. Evaluate: measure factual accuracy and refusal behaviour against adversarial prompts before launch.
4. Govern: route the proposal through the review body; assign an owner for ongoing monitoring.
5. Monitor: log outputs, sample for harm, and re-review when the model or customer base changes.

This progression — principles, governance, lifecycle review, tooling, culture, and iteration — is the mechanism that carries the business case and issue-spotting discipline of the earlier sections into everyday engineering practice, closing the gap between stated values and shipped systems.