[Class Report] Intro to System Development – Week 26: Designing Safe AI Integration into Apps (Advanced)

In Week 26, we built upon last week’s lessons on prompt creation and hands-on practice to explore how to safely integrate generative AI into our own applications. The focus was on practical design patterns and implementation strategies that ensure reliability and safety without compromising user experience.

■ Instructor’s Opening: “AI Is Just One Function — Design Makes It Safe”

Professor Tanaka: “Generative AI is powerful, but not always ‘correct’ on its own. That’s why it’s critical to define how we’ll handle input validation, output checking, and fallback behavior at the design stage.”

■ Core Learnings of the Day (Key Points)

1. Input Filtering (Preprocessing): Strip personal info or inappropriate language to prevent accidental data leaks.
2. Output Validation (Postprocessing / Fact-checking): Automate checks for plausibility, prohibited terms, and output format.
3. Fallback Design: If the AI fails, switch to local logic or template-based responses.
4. Transparency to the User: Clearly indicate AI involvement, confidence level, and caution messages.
5. Operational Measures (Audit Logs, Rate Limits, Caching): Manage API costs, ensure traceability, detect misuse.
6. Ethical & Legal Considerations: Design with respect for copyright, privacy, and bias mitigation.

■ Exercise ①: Input Sanitization & Approval Rules

We first created a preprocessing pipeline to ensure raw user input isn’t sent directly to the API.

• Blacklist filter for prohibited words
• Pattern detection for personal data (emails, phone numbers, addresses) → mask or remove
• Length & character restrictions → truncate and prompt summarization if needed

Example (Pseudocode)

def sanitize_input(text):
    text = mask_personal_info(text)
    if contains_prohibited(text):
        raise ValueError("Your input contains inappropriate terms. Please revise.")
    return truncate_if_needed(text, max_chars=1000)

Student reaction: “I almost submitted personal info by accident—it’s a relief that the system can catch that!”

■ Exercise ②: Output Validation Workflow

Before displaying the AI response, we passed it through several automated checks.

• Format validation (e.g., bullet lists, JSON, length)
• Prohibited word detection (discriminatory language, personal info)
• Flagging for fact-checking if key factual claims are present
• Attaching trust metadata (e.g., caution labels based on simple rules)

Example (Pseudocode)

def validate_output(output):
    if contains_prohibited(output):
        return ("fallback", "Inappropriate content detected. Displaying an alternative response.")
    if not matches_expected_format(output):
        return ("retry", "Output was not in the expected format. Regenerating.")
    if needs_fact_check(output):
        return ("confirm", "Some information needs verification. Only verified parts will be shown.")
    return ("ok", output)

Student comment: “It’s great that suspicious answers get flagged with a ‘needs confirmation’ label.”

■ Exercise ③: Fallback, Caching, and Rate Control

• Fallback: When the API fails, use pre-written templates or local data to respond.
• Caching: Store recent responses for short periods to reduce API calls (saves cost, avoids rate limits).
• Rate Limiting: Track API usage per time unit and apply limits when usage approaches thresholds.

Example (Pseudocode)

def get_response(prompt):
    key = cache_key(prompt)
    if cache.exists(key):
        return cache.get(key)
    try:
        resp = call_model_api(prompt, timeout=5)
        cache.set(key, resp, ttl=300)  # cache for 5 minutes
        return resp
    except TimeoutError:
        return local_fallback(prompt)

Student reaction: “Caching makes it faster and helps avoid overusing the API!”

■ Exercise ④: UI Transparency & User Control

We explored how to design UI that clearly communicates how AI is used.

• Show labels like “AI-generated suggestion”
• Provide buttons like “See Sources,” “Regenerate,” or “Request Human Review”
• Highlight AI trustworthiness and warnings in visible locations

Student impression: “UIs that don’t blindly trust AI feel way more reliable!”

■ Real-World Ops: Logging, Audits & Data Policy

The class also addressed operational design concerns.

• Audit Logging: Track all API calls (input, output, status) for accountability.
• Data Retention: Set policies for how long to store logs and user data, and anonymize where needed.
• Access Control: Limit who can view logs or sensitive data.

Prof. Tanaka: “Even in education settings, logging is vital — just remember to handle it with care and respect for privacy.”

■ Ethics Workshop: Case Study Discussions

In the second half, students worked in groups to analyze ethical dilemmas.

• Who is responsible if AI gives harmful outputs?
• What if a user copies AI content and suffers damage?
• How far can disclosure (“AI-generated,” source labels) reduce liability?

Student takeaway: “We need both proactive design and user-facing warnings to use AI responsibly.”

■ Instructor’s Closing Message

“Design is about creating ‘safety agreements.’ Only when you combine technical controls with clear user communication can you build apps that are both powerful and trustworthy.”

■ Homework: Applied Design Assignments

1. Create a flowchart for integrating generative AI into your mini app (input → check → API → validate → fallback → display).
2. List 3 input sanitization rules, and explain in 30–80 characters why each is necessary.
3. List 3 output validation checks, and write a one-line fallback action for each failure.

■ Coming Up Next Week: Implementation Hands-On

Next week, we’ll implement the design from this session in code. Using a school-approved safe environment, students will build a working module that includes preprocessing, postprocessing, caching, fallback logic, and API integration.

In this 26th session, students moved beyond viewing generative AI as just a “cool tool.” They learned to design it as a responsible, user-aware function—balancing power, safety, and usability.